New Python 3.0 string formatting - really necessary?

[MRAB]

Actually the new way has, at least three special symbols: ( '{', '}' ,
'.') as well as the method name "format" so

"%s=%s" % (k, v) for k, v in params.items()

becomes:

"{0}={1}".format((k, v) for k, v in params.items())

or something like that.

"{0}={1}".format(k, v) for k, v in params.items()

or:

"{0}={1}".format(*i) for i in params.items()

 

[r]

Just to be on record, i am OK with adding a new way to do this as long
as the old C style str format does not ever go away. I don't like 20
ways to do the same thing, but i really like the compact way of
%formating now. My complaint is the deprecation of %formating. Maybe
i'll use the new syntax to print a tuple or two, but that is the only
use i have for it .

Slowing down Python even more than it is, is suicide. Sure high level
languages are slower than there complied brethren, but a line has to
be drawn in the sand somewhere. As CPU speeds increase so does the
complexity's of modern software. GUI toolkits hog more resources as
they need eye pleasing "glass effects".

You can't just blindly Parrot off.. "well CPU's get faster every
year".

Python must stay fast, and simplistic(but not too simplistic), to
compete with other high level languages.

 

[Roy Smith]

Really? You know, it's funny, but when I read problems that people
have with python, I don't remember seeing that. Loads of people
complain about the white space issue. Some people complain about the
speed. Lots of complaints about certain quirky behavior, but I have
not come across any complaints about the string formatting.

In fact, from what I have seen, many of the "problems" being "fixed"
seem to be non-problems.

I dunno, maybe it's just me.

I had an interesting experience with this recently. I was giving a
co-worker quick python into. He's an experienced programer in various
languages, but this was his first exposure to python.

He got really hung up on the % syntax. By (bad) luck, he was trying to
print a tuple (let's call it "t"), did

format % t

and was surprised at the result. It set him off on a "but that's stupid,
blah, blah, blah" rant. I haven't absorbed the new syntax well enough to
figure out if people will get hung up by this with the new syntax.

 

[r]

Really? You know, it's funny, but when I read problems that people
have with python, I don't remember seeing that. Loads of people
complain about the white space issue. Some people complain  about the
speed. Lots of complaints about certain quirky behavior, but I have
not come across any complaints about the string formatting.

In fact, from what I have seen, many of the "problems" being "fixed"
seem to be non-problems.

I dunno, maybe it's just me.

You are exactly right Walter. I have not even considered this angle
yet. Most of the complaints i hear are the redundant use of self.
Which I lamented about but have become accustom(brainwashed) to it. I
would remove this if it where up to me. I also hear a lot of
complaints about speed. But never once in my life a problem with new
users and string formatting.

hmmm... food for thought

 

[MRAB]

Walter,

Would you be kind enough to translate this code to the new syntax?

'python 00012 1.33'

i want to see how casting is handled. Thanks

'python 00012 1.3'

 

[r]

I had an interesting experience with this recently.  I was giving a
co-worker quick python into.  He's an experienced programer in various
languages, but this was his first exposure to python.

He got really hung up on the % syntax.  By (bad) luck, he was trying to
print a tuple (let's call it "t"), did

format % t

and was surprised at the result.  It set him off on a "but that's stupid,
blah, blah, blah" rant.  I haven't absorbed the new syntax well enough to
figure out if people will get hung up by this with the new syntax.

It is stupid, more reason to fix the current problem instead creating
a whole new one.

One more big complaint "THE BACKSLASH PLAGUE". ever tried regexp?, or
file paths?. All because that little backslash char is a line
continuation character, maybe we should fix that. Would your life end
if '\' was not a continuation char? Mine would not because i don't
write my code to need it. Python has real warts that need fixing, and
thats really hard for me to say, because i am such a fanboy of Python.

 

[r]

Thanks MRAB,
except the float is not 2 decimal places, but its there

Come on... They did this for the interpreter not us. It's easer to
parse this string with positional arguments and a dict of format
descriptions. Come on pydev, at least be honest about it!

 

[bearophileHUGS]

walterbyrd:

As I understand it, that may have been true at one time. But, Ruby 1.9
very significantly sped up the language. While Python has been made
slower, Ruby has been made much faster.

I have already answered regarding Python3 in this thread. Regarding
Ruby you are right, in computer science there are lot of ways to speed
up things. So it may be quite possible for Ruby to become "faster"
than CPython.
For example this may speed up the PythonVM some:
"Optimizing direct threaded code by selective inlining":
http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.23.8829&rep=rep1&type=pdf

Bye,
bearophile

 

[Roy Smith]

You can't just blindly Parrot off.. "well CPU's get faster every
year".

Sure you can There was a nice treatment of this on slashdot today
(http://www.codinghorror.com/blog/archives/001198.html). The executive
summary is I'm willing to accept that Python is (big handwave) 10x slower
than C++, because *I'm* 10x faster writing in Python than I am in C++, and
I cost more than my computer.

Moore's laws says (small handwave) CPU speed doubles every 24 months. At
that rate, and assuming I remember enough high-school algebra to solve a
compound interest problem, hardware gets 10% faster every 3 months. If
Python gets 10% slower every 10 years or so, it's ahead of the curve.

 

[MRAB]

Thanks MRAB,
except the float is not 2 decimal places, but its there
Oops!

'python 00012 1.33'

 

[Steven D'Aprano]

It is stupid, more reason to fix the current problem instead creating a
whole new one.

Instead of just whinging, how about making a suggestion to fix it? Go on,
sit down for an hour or ten and try to work out how a BINARY OPERATOR
like % (that means it can only take TWO arguments) can deal with an
arbitrary number of arguments, *without* having any special cases.

Go on. Take your time. I'll be waiting.

One more big complaint "THE BACKSLASH PLAGUE". ever tried regexp?, or
file paths?. All because that little backslash char is a line
continuation character, maybe we should fix that.

This makes no sense whatsoever. How does the line continuation character
make any difference to backslashes inside a regex or a file path?

Again, instead of whinging, what's your suggestion to fix it? Another
suggestion, because your first:

Would your life end if '\' was not a continuation char?

is just stupid. The line continuation character is *irrelevant* to the
problem of backslashes inside strings. For all the use it is, you might
as well suggest changing the name None to Null.

 

[Steven D'Aprano]

Really? You know, it's funny, but when I read problems that people have
with python, I don't remember seeing that. Loads of people complain
about the white space issue. Some people complain about the speed. Lots
of complaints about certain quirky behavior, but I have not come across
any complaints about the string formatting.

There are some things that some people whinge about, often just to hear
the sound of their own voice (or the look of their own font, if you
prefer). Whitespace and speed are two of those: they attract trolls and
sooks.

(That's not to say that there aren't real problems related to them. But
it seems to me that the real problems are drowned out by the trolls.)

Then there are things that people don't complain about, they just shrug
and code a work-around. If % doesn't do what you want, do you cry about
it, or do you code around it?

I can't speak for others, but what I did was ask the question, discover
that % was not powerful enough, and coded around it:

http://mail.python.org/pipermail/python-list/2006-April/376641.html

In fact, from what I have seen, many of the "problems" being "fixed"
seem to be non-problems.

I dunno, maybe it's just me.

It's just you.

Sheesh, I've never seen such a bunch of cry-babies sooking that their
favourite language just got *more* power and flexibility. If
functionality was being removed, I could understand the response, but
this? It's just crazy.

 

[r]

Instead of just whinging, how about making a suggestion to fix it? Go on,
sit down for an hour or ten and try to work out how a BINARY OPERATOR
like % (that means it can only take TWO arguments) can deal with an
arbitrary number of arguments, *without* having any special cases.

Go on. Take your time. I'll be waiting.


This makes no sense whatsoever. How does the line continuation character
make any difference to backslashes inside a regex or a file path?

Again, instead of whinging, what's your suggestion to fix it? Another
suggestion, because your first:


is just stupid. The line continuation character is *irrelevant* to the
problem of backslashes inside strings. For all the use it is, you might
as well suggest changing the name None to Null.

i prefer None over Null myself, just another Pythonic beauty!

Steven,
Would you like to elaborate on -why- escaped backslashes are needed in
strings... i waiting???

 

[Aaron Brady]

Instead of just whinging, how about making a suggestion to fix it? Go on,
sit down for an hour or ten and try to work out how a BINARY OPERATOR
like % (that means it can only take TWO arguments) can deal with an
arbitrary number of arguments, *without* having any special cases.

Go on. Take your time. I'll be waiting.

Hi, not to take sides, but, there is a possibility.

This behavior is currently legal:
'0 1'

So, just extend it. (Unproduced.)
'(2, 3, 4) %i'

Which is quite clever and way ahead of its (posessive) time.

 

[Steven D'Aprano]

Just to be on record, i am OK with adding a new way to do this as long
as the old C style str format does not ever go away. I don't like 20
ways to do the same thing, but i really like the compact way of
%formating now.

% formatting isn't compact unless you are only doing trivial
substitutions.

My complaint is the deprecation of %formating.

% formatting hasn't been deprecated. All this Sturm und Drang over
nothing.

Maybe
i'll use the new syntax to print a tuple or two, but that is the only
use i have for it .

Good for you. If your code is that trivial, then you're lucky.

Slowing down Python even more than it is, is suicide.

Oh noes, we're all gonna die!!!

Just out of curiosity "r", how old are you? 14? 15? You're remarkably
mature for a 15 year old.

 

[Steven D'Aprano]

Would you like to elaborate on -why- escaped backslashes are needed in
strings... i waiting???

If you can't escape backslashes in strings, how do you create a string
containing a backslash?

 

[MRAB]

walterbyrd:

I have already answered regarding Python3 in this thread. Regarding
Ruby you are right, in computer science there are lot of ways to speed
up things. So it may be quite possible for Ruby to become "faster"
than CPython.
For example this may speed up the PythonVM some:
"Optimizing direct threaded code by selective inlining":
http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.23.8829&rep=rep1&type=pdf

Interesting. The re module uses a form of bytecode. Not sure about the
relative cost of the dispatch code, though.

 

[r]

Answering a question with a question, that leaves me with a question
of my own??

Instead of just whinging, how about making a suggestion to fix it? Go on,
sit down for an hour or ten and try to work out how a BINARY OPERATOR
like % (that means it can only take TWO arguments) can deal with an
arbitrary number of arguments, *without* having any special cases.

Instead of being a blind fanboy and chastising everyone who dares to
question pydev, Guido, or YOU... why don't you offer a good rebuttal?
If i did not give a rats behind about Python i would not be here
arguing with you. I would give up and "require" my packages . I
prefer to import

I believe Python has the best chance of surviving and becoming the
king of high level languages, IF we don't muck it up!

 

[Steven D'Aprano]

Hi, not to take sides, but, there is a possibility.

This behavior is currently legal:

'0 1'

So, just extend it. (Unproduced.)

'0 1'

Errors should never pass silently, unless explicitly silenced. You have
implicitly silenced the TypeError you get from not having enough
arguments for the first format operation. That means that you will
introduce ambiguity and bugs.

"%i %i %i %i" % 5 % 3 %7

Here I have four slots and only three numbers. Which output did I expect?

'%i 5 3 7'
'5 %i 3 7'
'5 3 %i 7'
'5 3 7 %i'

Or more likely, the three numbers is a mistake, there is supposed to be a
fourth number there somewhere, only now instead of the error being caught
immediately, it won't be discovered until much later.


(BTW, if you want that behaviour, you should look at the string module.)

 

[Steven D'Aprano]

Answering a question with a question, that leaves me with a question of
my own??


Instead of being a blind fanboy and chastising everyone who dares to
question pydev, Guido, or YOU... why don't you offer a good rebuttal?

Because I thought it was obvious even you could see it. I'm disappointed
to be proven wrong.

A binary operator can only take two arguments: one on the left, and one
on the right:

2 + 3
5 * 7
x == 2
"%i" % 7

The typical use-case for string formatting operations requires more than
two arguments. Since % is a binary operator, it can only take two
arguments. One of those arguments must be the template string, so the
other argument has to wrap all the rest of the arguments into one object:

"The %s ate %d slices of %s." % ("python", 7, "spam")

Python could have insisted that even single arguments be wrapped in a
tuple:

"%s" % ("python",)

At the cost of breaking backwards compatibility, that would solve the
problem of treating tuples as a special case, but it seems wasteful and
silly to be forced to write this:

"The answer is: %d" % (5,)

instead of

"The answer is: %d" % 5

especially when people will invariably leave out the comma and then
complain about the "wart" or "bug" that:

"The answer is: %d" % (5)

doesn't do what they expect. So tuples are treated as a special case: you
only need to wrap a single argument in a tuple if that argument itself is
a tuple:

"%s" % ((0, 1, 2),)

and everything else just works as you would expect.

Again, at the cost of breaking backwards compatibility, Python could
change the special case from tuples to something else, but what? And why
bother? There will always be a special case, one way or another.

Consequently, there is no way to "fix" the special casing of tuples
without just shifting the problem. The problem is fundamental to the
nature of binary operators: you can't fit an arbitrary number of
arguments into two places (the left hand side, and the right hand side)
of the % operator without having to special case something.

The real solution is to stop trying to force arbitrary numbers of
arguments into a single place, and instead use a function or method that
takes multiple arguments. That's what the "".format() method and the
format() function do.