Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #58223 > unrolled thread

Re: Python wart

Back to article view | Back to comp.lang.python

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: Python wart Chris Angelico <rosuav@gmail.com> - 2013-11-01 12:54 +1100
    Re: Python wart Peter Cacioppi <peter.cacioppi@gmail.com> - 2013-11-01 00:11 -0700
      Re: Python wart Chris Angelico <rosuav@gmail.com> - 2013-11-01 18:59 +1100
      Re: Python wart Mark Lawrence <breamoreboy@yahoo.co.uk> - 2013-11-01 09:08 +0000
      Re: Python wart Chris Angelico <rosuav@gmail.com> - 2013-11-01 20:17 +1100
      Re: Python wart Mark Lawrence <breamoreboy@yahoo.co.uk> - 2013-11-01 09:32 +0000
      Re: Python wart Chris Angelico <rosuav@gmail.com> - 2013-11-01 20:42 +1100
    Re: Python wart Peter Cacioppi <peter.cacioppi@gmail.com> - 2013-11-01 14:47 -0700
      Re: Python wart Chris Angelico <rosuav@gmail.com> - 2013-11-02 10:13 +1100
    Re: Python wart Peter Cacioppi <peter.cacioppi@gmail.com> - 2013-11-01 18:11 -0700
      Re: Python wart Chris Angelico <rosuav@gmail.com> - 2013-11-02 12:18 +1100
    Re: Python wart Peter Cacioppi <peter.cacioppi@gmail.com> - 2013-11-01 18:26 -0700

#58223 — Re: Python wart

On Fri, Nov 1, 2013 at 12:53 PM, Chris Angelico <rosuav@gmail.com> wrote:
> orig_print = print
> def print(fmt, *args, **kwargs):
>     orig_print(fmt%args, **kwargs)

PS. To be courteous to subsequent developers, you might want to
instead leave print as it is, and create your own printf:

def printf(fmt, *args, **kwargs):
    print(fmt%args, **kwargs)

Take your pick, whichever way works for you.

ChrisA

[toc] | [next] | [standalone]

#58242

Mark said : 

"Do I have to raise a PEP to get this stupid language changed so that it
dynamically recognises what I want it to do and acts accordingly?"

The printf syntax in C isn't any wonderful thing, and there is no obligation to provide some Python version of it. 

I have to say, there were a few things that twerked me when getting up to speed on Py, but formatting strings wasn't one of them. I'd be surprised if Guido prioritizes a fix for this part of his "stupid language". 

Just sayin

[toc] | [prev] | [next] | [standalone]

#58244

On Fri, Nov 1, 2013 at 6:11 PM, Peter Cacioppi <peter.cacioppi@gmail.com> wrote:
> The printf syntax in C isn't any wonderful thing, and there is no obligation to provide some Python version of it.

Maybe, but it's supported by so many languages that it is of value.
Though Python's use of the % operator does lead to edge cases (a
single argument, except if it's a tuple, even though a tuple could be
accepted by %r), so a printf() function might be cleaner.

ChrisA

[toc] | [prev] | [next] | [standalone]

#58248

On 01/11/2013 07:11, Peter Cacioppi wrote:
> Mark said :
>
> "Do I have to raise a PEP to get this stupid language changed so that it
> dynamically recognises what I want it to do and acts accordingly?"
>
> The printf syntax in C isn't any wonderful thing, and there is no obligation to provide some Python version of it.
>
> I have to say, there were a few things that twerked me when getting up to speed on Py, but formatting strings wasn't one of them. I'd be surprised if Guido prioritizes a fix for this part of his "stupid language".
>
> Just sayin
>

I'm heading into town in maybe an hour.  I'll stop here 
http://www.toolbankexpress.com/shop/castle/ so I can get an extremely 
large pair of pliers with which I can extract my tongue from my cheek :)

-- 
Python is the second best programming language in the world.
But the best has yet to be invented.  Christian Tismer

Mark Lawrence

[toc] | [prev] | [next] | [standalone]

#58249

On Fri, Nov 1, 2013 at 8:08 PM, Mark Lawrence <breamoreboy@yahoo.co.uk> wrote:
> I'm heading into town in maybe an hour.  I'll stop here
> http://www.toolbankexpress.com/shop/castle/ so I can get an extremely large
> pair of pliers with which I can extract my tongue from my cheek :)

I think you may have a bit of trouble. The part where you demanded the
language dynamically figure out what you wanted may have gotten your
tongue rather stuck there...

The neat thing about this list is that even posts like that can result
in real solutions :)

ChrisA

[toc] | [prev] | [next] | [standalone]

#58251

On 01/11/2013 09:17, Chris Angelico wrote:
> On Fri, Nov 1, 2013 at 8:08 PM, Mark Lawrence <breamoreboy@yahoo.co.uk> wrote:
>> I'm heading into town in maybe an hour.  I'll stop here
>> http://www.toolbankexpress.com/shop/castle/ so I can get an extremely large
>> pair of pliers with which I can extract my tongue from my cheek :)
>
> I think you may have a bit of trouble. The part where you demanded the
> language dynamically figure out what you wanted may have gotten your
> tongue rather stuck there...
>
> The neat thing about this list is that even posts like that can result
> in real solutions :)
>
> ChrisA
>

Absolutely correct.

This thread actually got me thinking[1].  There's a thread on Python 
ideas about "where did we go wrong with negative stride?".  It discusses 
maybe fixing this for Python 4.  I wondered if the idea of deprecating 
printf style formatting might also come up again.  It was discussed in 
some depth here 
https://mail.python.org/pipermail/python-dev/2012-February/116789.html

[1] yes it does happen, yes you may joke about it and yes I can take the 
jokes, I certainly deserve them :)

-- 
Python is the second best programming language in the world.
But the best has yet to be invented.  Christian Tismer

Mark Lawrence

[toc] | [prev] | [next] | [standalone]

#58253

On Fri, Nov 1, 2013 at 8:32 PM, Mark Lawrence <breamoreboy@yahoo.co.uk> wrote:
> I wondered if the idea of deprecating printf style formatting might also
> come up again.  It was discussed in some depth here
> https://mail.python.org/pipermail/python-dev/2012-February/116789.html

I don't see any reason for it to go. Anyone who wants to use .format()
is welcome to; anyone who likes %s is welcome to use that. They have
sufficiently distinct styles that they don't really come into
conflict. Now, if someone wants to deprecate the "str modulo anything"
operator in favour of an explicit sprintf() function (optionally with
printf() that sends straight through to print()), that I might get
behind - but I don't see any reason to lose the printf-style
formatting codes.

ChrisA

[toc] | [prev] | [next] | [standalone]

#58293

Mark said :

"so I can get an extremely large pair of pliers with which I can extract my tongue from my cheek :) "

OK fair enough, and my post was in the same spirit.

Chris said :

"Maybe, but it's supported by so many languages that it is of value. "

Sure, I suppose someone should make a module that gets you as close as possible within the as-is language definition. I can't really comment on whether Py is close enough currently, as I always thought printf was sort of crappy. 

I thought the C++ << business even worse. 

Like I said, Python seems fine to me in this area. I use the str(), round() and ljust(), rjust() functions and concatenate what I need together. The result seems more readable than the old printf crap I used to write (not exactly clearing a sky high bar).

Just one man-child's opinion.

[toc] | [prev] | [next] | [standalone]

#58298

On Sat, Nov 2, 2013 at 8:47 AM, Peter Cacioppi <peter.cacioppi@gmail.com> wrote:
> I always thought printf was sort of crappy.
>
> I thought the C++ << business even worse.

Oh, you'll get no argument from me about the std::*stream types! When
I write C++ code, I almost exclusively use C-style formatted strings,
even sometimes going to the extent of using fopen() just so I can use
fprintf() rather than fstream. Also, I often create a class something
like this:

struct format
{
    char *data;
    format(const char *fmt, ...);
    operator char *() {return data;}
};

where the constructor calls vsprintf and there's a bit of new/delete
work to manage memory, but that's all under the covers; in code, I use
it like this:

some_function_call(format("Hello, %s!", "world"));

making it almost as if it's a function returning a string, like you
would in Python.

Most of the problems with printf come from the fragility of C's
variadic functions. Some C compilers can deal with that (gcc happily
checks printf args), but there are still fundamentally hard problems
around it. They don't apply in Python (or Pike, which has an sprintf
function[1] with even more power), as issues can be signalled with
exceptions - clean, easy, safe.

ChrisA

[1] http://pike.lysator.liu.se/generated/manual/modref/ex/predef_3A_3A/sprintf.html

[toc] | [prev] | [next] | [standalone]

#58303

Chris said :

" I almost exclusively use C-style formatted strings, even sometimes going to the extent of using fopen() just so I can use fprintf() rather than fstream. Also, I often create a class something like this: "

Ditto all that, to include the special class I cooked up to handle printf issues in an object based way.

In general, I liked all the C++ additions a lot. I really liked the STL. But I don't know what Bjarne was thinking with the streams.

[toc] | [prev] | [next] | [standalone]

#58304

On Sat, Nov 2, 2013 at 12:11 PM, Peter Cacioppi
<peter.cacioppi@gmail.com> wrote:
> In general, I liked all the C++ additions a lot. I really liked the STL. But I don't know what Bjarne was thinking with the streams.

It does look cool on paper. You can "see" the flow of data.
Everything's type-safe - unlike C's scanf family (though, again,
sscanf in a high level language can get around that problem). The only
problem is, it doesn't actually help much in code. It's snazzy but not
all that useful.

ChrisA

[toc] | [prev] | [next] | [standalone]

#58305

Chris said :

"It does look cool on paper. "

Sure, I'll buy that Bjarne designed something intellectually pretty that just doesn't flow very well in practice. Most of his C++ worked very well both in theory and practice, so I can forgive him one nerdy overreach, if that's what it was.

Python is impressive for it's lack of such constructions. Things are pretty to think about, and handy to use. 

What is it the French say? "Sure it works in practice, but does it work on paper?" ;) I can joke, I once had many very smart French colleagues.

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.python

csiph-web