New Python 3.0 string formatting - really necessary?

[walterbyrd]

I have not worked with Python enough to really know. But, it seems to
me that more I look at python 3.0, the more I wonder if it isn't a
step backwards.

To me, it seems that this:

print "%s=%d" % ('this',99)

Is much easier, and faster, to type, and is also easier to read and
understand. It also allows people to leverage their knowledge of C.

This (if it's right) is much longer, and requires more special
characters.

print( "{0}={1}".format('this',99))

Maybe it's worth all the extra trouble, and breaking backward
compatibilty, and all. But, I never had the idea that the old way was
all that big a problem. Of course, I could be wrong. Was the old way
all that big of a problem?

 

[Giampaolo Rodola']

I have not worked with Python enough to really know. But, it seems to
me that more I look at python 3.0, the more I wonder if it isn't a
step backwards.

To me, it seems that this:

print "%s=%d" % ('this',99)

Is much easier, and faster, to type, and is also easier to read and
understand. It also allows people to leverage their knowledge of C.

This (if it's right) is much longer, and requires more special
characters.

print( "{0}={1}".format('this',99))

Maybe it's worth all the extra trouble, and breaking backward
compatibilty, and all. But, I never had the idea that the old way was
all that big a problem. Of course, I could be wrong. Was the old way
all that big of a problem?

You can use the old 2.x syntax also in Python 3.x:


C:\>C:\python30\python.exe
Python 3.0 (r30:67507, Dec 3 2008, 20:14:27) [MSC v.1500 32 bit
(Intel)] on win
32
Type "help", "copyright", "credits" or "license" for more information.this=99


--- Giampaolo
http://code.google.com/p/pyftpdlib/

 

[r]

if 3.0 looks like... print( "{0}={1}".format('this',99)) , WTF...
thats retarded and looks like Ruby code. Thats not intuitive thats
madness! What happens when you need a conversion to string from an
integer, more code?? My faith is slipping. Have the python Gods gone
mad??. Please tell me i am wrong.

Pythons likeness to C is one of its great powers. I always thought of
Python as an intuitive way to write C code.

I am sticking with 2x(which i had planned to do anyway) I have heard
of nothing significant enough to compel me to make the change yet. And
with that example from 3.0, i am really setting my ways now. i may
have to support the continuation of 2.x beyond 2.9.

Guido! please don't play Russian roulette with Python! I have loved
python all the way up through the 2.x line. And i carry a great
respect for you and your accomplishments. Python must feel at home to
a C programmer. That, i feel, is the professional following for
Python. I also feel Python is a gateway to the C language for n00b
programmers. Let Ruby have the Perl programmers, we don't need them!

Excuse me, I think i am going to cry now

 

[walterbyrd]

You can use the old 2.x syntax also in Python 3.x:

Yeah, but it's deprecated, and - as I understand it - may be removed
completely in future versions. Also, in the future, if you are working
with code from another developer, it's likely that developer will use
the new format. I suppose you can use both - but what an awful mess
that would be.

It seems to me that 3.0 is changing a lot of non-problems. And it's
going to be slower to boot.

 

[Michael Torrie]

if 3.0 looks like... print( "{0}={1}".format('this',99)) , WTF...
thats retarded and looks like Ruby code. Thats not intuitive thats
madness! What happens when you need a conversion to string from an
integer, more code?? My faith is slipping. Have the python Gods gone
mad??. Please tell me i am wrong.

You are wrong.

Pythons likeness to C is one of its great powers. I always thought of
Python as an intuitive way to write C code.

I have to confess, I have no idea what you are talking about. I have
never ever seen Python as an intuitive way to write C code. That's kind
of bizarre.

I am sticking with 2x(which i had planned to do anyway) I have heard
of nothing significant enough to compel me to make the change yet. And
with that example from 3.0, i am really setting my ways now. i may
have to support the continuation of 2.x beyond 2.9.

Guido! please don't play Russian roulette with Python! I have loved
python all the way up through the 2.x line. And i carry a great
respect for you and your accomplishments. Python must feel at home to
a C programmer. That, i feel, is the professional following for
Python. I also feel Python is a gateway to the C language for n00b
programmers. Let Ruby have the Perl programmers, we don't need them!

Excuse me, I think i am going to cry now

Okay, you're welcome to.

So funny that now that Python 3.0 is actually released we have people
acting all surprised like they've never seen any of the new features in
Python 3.0 coming. However these features have been discussed for
years! And debated!

Personally the new string formatter is sorely needed in Python. And
they way it has been implemented is a thing of beauty. Basically the
burden of formatting strings has been moved from the print
statement/function to the objects themselves. Furthermore, the new {}
notation allows many, many more options for formatting to be used. Want
to display a floating point number with $#.## notation, and ($#.##) for
negative? It's all now possible. Couldn't be done before. Want to
have the ability to format your own custom object in a particular way
when printing with print()? Just define a __format__ method in your
object. print() will ask it to format itself.

In short, this is a huge improvement, and backwards compatibility is
preserved for the 2.x style for those that wish it.

 

[Michael Torrie]

Yeah, but it's deprecated, and - as I understand it - may be removed
completely in future versions. Also, in the future, if you are working
with code from another developer, it's likely that developer will use
the new format. I suppose you can use both - but what an awful mess
that would be.

It seems to me that 3.0 is changing a lot of non-problems. And it's
going to be slower to boot.

How is this? With projects like PyPy eventually enabling the JIT'ing of
python3 code, I don't see how this is going to be "slower." If anything
we have a python that can be made to run faster than ever before.

Please qualify your remarks. Are you a Python core developer?

 

[r]

I was actually looking forward to 3.0, but the more I hear about 3.0,
the more I am turned off. I think there are a lot of other
pythonista's and pythoneers out there who agree but are not saying
anything. This syntax for string formatting is completely ridiculous.
What is the purpose of breaking backward compatibility just to write a
print() function. This is going to push people away from python. I am
trying to bring people to Python. I heard map is going away too, is
that true also??, and there was talk at one time(serious talk from
Guido) about removing lambda functions. Is this planned for the
future??

Python has been beautifully designed from the beginning. But, I feel a
shift from this now. Are they scared of Ruby, if they are, why the
hell should they be. We do not need to lose any of the great
pythonista's right now, and we damn sure don't want to turn off the
new recruits.

It seems like most of the backward breaks are really just for dumb
reasons(sorry but its true). What is the logic behind this? The whole
reason for not having a print function was the need to use it so much
in debugging. And I was actually going to overlook that until I saw
this perl/ruby like format method. WTF!

 

[bearophileHUGS]

r:

I always thought of Python as an intuitive way to write C code.<

C is a very low level language, not far from assembly, and often it's
not intuitive at all.

C string formatting is short and a flexible enough, but it's out of
place in a language as high level as Python3. The new syntax allows
more flexibility, and it's better for most people that don't know C
already, like newbies, etc.

------------------

walterbyrd:

It seems to me that 3.0 is changing a lot of non-problems. And it's

going to be slower to boot.<

They are non-problems for people that already know lot of Python (and
some C). But for all the other people, especially newbies, it's better
in most things.

Most language designers (and generally people very used a certain
language) become so accustomed to their language that they most of the
times become like "blind" to the defects and warts of their language
(I have said this four years ago too, when I have started learning
Python, listing many problems in Python, and among them there were C
string formatting too). So I think it was a feat for the Python
developers to see many characteristics of the Python2.x as what they
are: warts, bugs, etc, and fix them (and most of the times their newer
designs are "the right thing" with just few exceptions, I have counted
only 3 of them, and they are small). They have gained even more of my
respect.

Regarding the speed of Python3 programs, they will go faster because
people will be forced to use things like lazy ranges, lazy map and
filter, lazy keys and values, and the "key" of sort/sorted. All those
things can be used in Python2.x too, but lot of people aren't expert
enough (or they are just lazy) and don't use them, so the average
Python3 program will probably be faster (and use less memory) thanks
to them.

Python3 programs will go slower because they use 2-byte long Unicode
strings by default (it can be compiled for 4-byte Unicode too, and I
think this has to become the default, eventually, because I think it
will become silly to save few bytes for strings when you will have
8-16-32+ GB of RAM), and they use multi-precision integers only. Such
strings and numbers allow to reduce some troubles, even "bugs", etc.

At the moment Python3 isn't much optimized for speed, you can think of
it an experimental release still. I/O and multiprecision integers will
probably be speed up (and some form of transparent on-the-fly
compression or smart representation can in most times halve the memory
used by Py3 strings, putting the performance almost back to the Py2.x
one. In computer science there are LOT of tricks that can be used if
you have the brain and time to invent and implement them. You can see
that for example in how Psyco manages internally string/list/tuple
slices).

Anyway, CPUs and computers are now much faster than the CPUs present
when Python was created. And Python is first of all designed for the
programmer and not for the CPU. So I think it's right to make Python3
become a little higher level language even if this slows it down a
little. For the kind of programs Python is often used for, I think
this is a Win. (Ruby programs are often slower than Python ones
(because Ruby is a little higher level than Python) but it's very
useful anyway). If Python will continue to develop in the following
years (think about a Python4000) then I think it may become good to
make it become even more slower, if this will help make it a little
more higher level still.

Bye,
bearophile

 

[MRAB]

r:

C is a very low level language, not far from assembly, and often it's
not intuitive at all.

C string formatting is short and a flexible enough, but it's out of
place in a language as high level as Python3. The new syntax allows
more flexibility, and it's better for most people that don't know C
already, like newbies, etc.

------------------

walterbyrd:
going to be slower to boot.<

They are non-problems for people that already know lot of Python (and
some C). But for all the other people, especially newbies, it's better
in most things.

Most language designers (and generally people very used a certain
language) become so accustomed to their language that they most of the
times become like "blind" to the defects and warts of their language
(I have said this four years ago too, when I have started learning
Python, listing many problems in Python, and among them there were C
string formatting too). So I think it was a feat for the Python
developers to see many characteristics of the Python2.x as what they
are: warts, bugs, etc, and fix them (and most of the times their newer
designs are "the right thing" with just few exceptions, I have counted
only 3 of them, and they are small). They have gained even more of my
respect.

Regarding the speed of Python3 programs, they will go faster because
people will be forced to use things like lazy ranges, lazy map and
filter, lazy keys and values, and the "key" of sort/sorted. All those
things can be used in Python2.x too, but lot of people aren't expert
enough (or they are just lazy) and don't use them, so the average
Python3 program will probably be faster (and use less memory) thanks
to them.

Python3 programs will go slower because they use 2-byte long Unicode
strings by default (it can be compiled for 4-byte Unicode too, and I
think this has to become the default, eventually, because I think it
will become silly to save few bytes for strings when you will have
8-16-32+ GB of RAM), and they use multi-precision integers only. Such
strings and numbers allow to reduce some troubles, even "bugs", etc.

At the moment Python3 isn't much optimized for speed, you can think of
it an experimental release still. I/O and multiprecision integers will
probably be speed up (and some form of transparent on-the-fly
compression or smart representation can in most times halve the memory
used by Py3 strings, putting the performance almost back to the Py2.x
one. In computer science there are LOT of tricks that can be used if
you have the brain and time to invent and implement them. You can see
that for example in how Psyco manages internally string/list/tuple
slices).

Anyway, CPUs and computers are now much faster than the CPUs present
when Python was created. And Python is first of all designed for the
programmer and not for the CPU. So I think it's right to make Python3
become a little higher level language even if this slows it down a
little. For the kind of programs Python is often used for, I think
this is a Win. (Ruby programs are often slower than Python ones
(because Ruby is a little higher level than Python) but it's very
useful anyway). If Python will continue to develop in the following
years (think about a Python4000) then I think it may become good to
make it become even more slower, if this will help make it a little
more higher level still.

I would've hoped that Python 4000 would address the internals (JIT) just
as Python 3000 addressed the externals.

 

[r]

~Michael,
What’s next down this road of self destruction? Hey guys, forget about
about empty parenthesis on a function/method call, we should not have
to waste are time typing them… Wait forget about them all together and
we will just write Ruby code…

Def function arg arg arg arg arg arg

“Yea, that looks good“.insert(sarcasm)
Things like forcing empty tuple on function/method calls are what make
python so great. Python dumped the C bracket plague, but enforces
parenthesis even for a no argument function. But hell, why shouldn’t
we have 50 ways to the same thing in Python like Ruby.

PS. Don’t discredit Walter just because he is not on the dev team,
that don’t mean squat!


~Bearophile,
Thanks for your civil approach to this conversation but I must
disagree with you on the new string formatting syntax. You said the
new syntax is suppost to be easier on the n00b , I say it pollutes a
students mind. What is wrong with similarities to C formatting, I
find nothing complicated about it.

%s (means put a string here)
%d (means put a integer here)
%f (means put a float here)

It does not get any simpler than that, and this will just ease the
transition to C programming for this student. Lets not forget how
important C is!

I always likened Python to my cool uncle who would let me get away
with more than my parents-C- but would enforce the important rules.
Like Python’s forcing of empty tuple in function calls, that is a good
idea. This allows you to clearly see arguments in source code. I like
in Python there is only one, or a very minimal number of ways to do
something(but usually only one is the best). Ruby is littered with
different ways to do the same thing. I think this will be Ruby’s
undoing…. And Pythons if we follow down this road.

And lets not forget Python forcing of indention, that is Pythons
greatest strength!

 

[excord80]

To me, it seems that this:

print "%s=%d" % ('this',99)

Is much easier, and faster, to type, and is also easier to read and
understand. [snip]

This (if it's right) is much longer, and requires more special
characters.

print( "{0}={1}".format('this',99))

Yeah, I like the old way better too. It's got this nice elegant
simplicity to it (using the percent sign for not only the things
inside the string, but also to separate it from the tuple that
follows). Also, I like having only *one* special symbol (`%') to worry
about in my strings instead of two (`{' and `}').

But, Python is Python. So I'll keep using the old way until they
deprecate it, and then just get used to the new way. One reason I use
Python is because I really *don't* have the time or inclination to
question every little design decision and argue about alternatives. If
you want to tweak the language to suit your personal tastes, you might
prefer Perl 6.

 

[Carl Banks]

~Michael,
What’s next down this road of self destruction? Hey guys, forget about
about empty parenthesis on a function/method call,  we should not have
to waste are time typing them… Wait forget about them all together and
we will just write Ruby code…

Def function arg arg arg arg arg arg

“Yea, that looks good“.insert(sarcasm)
Things like forcing empty tuple on function/method calls are what make
python so great. Python dumped the C bracket plague,  but enforces
parenthesis even for a no argument function. But hell, why shouldn’t
we have 50 ways to the same thing in Python like Ruby.

PS. Don’t discredit Walter just because he is not on the dev team,
that don’t mean squat!

~Bearophile,
Thanks for your civil approach to this conversation but I must
disagree with you on the new string formatting syntax. You said the
new syntax is suppost to be easier on the n00b , I say it pollutes a
students mind. What is wrong with similarities to C formatting,  I
find nothing complicated about it.

%s (means put a string here)
%d (means put a integer here)
%f (means put a float here)

It does not get any simpler than that,

No, you just think it's easiest because that's the way you learned it.

I'm kind of ambivalent about the change (it does have a couple minor
drawbacks), but I don't see any way that the new method isn't easier
to learn than the old--especially if you want to do more advanced
formatting--unless you already knew the old method.

I really don't like that they made format a string method, though, I
would have hoped for a built-in, and why didn't they abbreviate this
one? If any function or method would have had a case for an
abbreviated name, this was it. But just about anything is better than
that % operator and its multi-level confusion involving tuple syntax,
operator precedence, and special-casing of tuples and dicts.

and this will just ease the
transition to C programming for this student. Lets not forget how
important C is!

C programmers who learn Python have to learn all kinds of new things,
a new string formating method would be a minor one. As for everyone
else, they'll probably have an easier time of it.


Carl Banks

 

[Marc 'BlackJack' Rintsch]

~Bearophile,
Thanks for your civil approach to this conversation but I must disagree
with you on the new string formatting syntax. You said the new syntax is
suppost to be easier on the n00b , I say it pollutes a students mind.
What is wrong with similarities to C formatting, I find nothing
complicated about it.

%s (means put a string here)
%d (means put a integer here)
%f (means put a float here)

It does not get any simpler than that,

Well for those simple cases you could simply use '%s' for strings,
integers, and floating point objects in Python. But '{0}' isn't more
complicated. But you get the extra flexibility to decouple the order in
the string and the order of the objects to be formatted.

and this will just ease the transition to C programming for this
student. Lets not forget how important C is!

To a Python "n00b"? Not important at all. Beside the point that '%s' is
still possible -- someone who knows C but struggles with replacing '%s'
by '{0}' has far greater problems.

Ciao,
Marc 'BlackJack' Rintsch

 

[Steve Holden]

r wrote:
[...]

Like Python’s forcing of empty tuple in function calls, that is a good
idea. This allows you to clearly see arguments in source code. I like
in Python there is only one, or a very minimal number of ways to do
something(but usually only one is the best). Ruby is littered with
different ways to do the same thing. I think this will be Ruby’s
undoing…. And Pythons if we follow down this road.

And lets not forget Python forcing of indention, that is Pythons
greatest strength!

Kindly allow me to disabuse you of the notion that a function call with
no arguments is a function reference followed by an empty tuple. It
might *look* like that, but it isn't. Otherwise we'd write a function
call with one argument as f(a, ) - which readers will have noticed we don't.

regards
Steve

 

[Aaron Brady]

But, Python is Python.

It's always surprising to me to hear this, but especially so in
writing.

It speech, it has connotations. A millionaire can say (dismissively),
"Two bucks is two bucks." A poor person can say (wondrously), "Two
bucks is two bucks." Without knowing the expository (the facts about
the speakers), you could glean some of the context from the tone and
pitch. You could say, 'The speaker sounds wondrous', or 'The speaker
sounds dismissive.' I take the repetition to mean, roughly, 'But
these is the speaker's overall evaluation of the subject.'

The stereotypical case is a girl or boy in a tough social situation;
and I don't know what countries they do this in, or even how
widespread it is in mine. A friend says, "What s/he is doing is no
good." You say, "But it's [person's name]."

Literally, that doesn't add any information to the debate, which is
stereotypically over a decision or resolution. It does facilitate
expression (free expression is good), but I think it would have been
more productive, informative, fruitful, etc., to leave the last word
with the opposition; that is, when the friend says, "What s/he is
doing is no good." Period. The facts merit it, and it's merely
escapist to withdraw back to the big picture, since it is the small
details in the situation that need the concentration and attention.

Without context, in writing, 'Two bucks is two bucks' is exactly the
same as 'Two bucks is two bucks'. Readers can't hear pitch, and do
not have context about fiscal status. Excord, was your tone
dismissive, or wondrous? Or a little whiny? Or authoritative? The
statement carried no more information than "A square is a square" or
"A bachelor is unmarried", and to readers, even lacked the expressive
value too. (No .WAV file attached!)

 

[r]

Scott,
Oh, so Python 3.0 is an Equal Opportunity Enigma, now i get it

Steve,
Obviously i was referring to the look, not the actuality of a tuple

Marc,
Why move away from a concise and widely accepted way of sting
formatting, just to supposedly make it a little easier for n00bs?
(which i disagree this is easier) In turn, creating more syntactical
clutter. (%s %f %d) is all you need to remember. If people can't
understand that, i fear for the future of Humans as a species!

[bearophile],
"""So I think it's right to make Python3 become a little higher level
language even if this slows it down a little. For the kind of
programs Python is often used for, I think this is a Win. (Ruby
programs are often slower than Python ones (because Ruby is a little
higher level than Python) but it's very useful anyway). If Python will
continue to develop in the following years (think about a Python4000)
then I think it may become good to make it become even more slower, if
this will help make it a little more higher level still."""
[/bearophile],

Yea, if your keeping up with the "Rubies" i guess. Python's strengths
are in it's simplicity -and- it's constraints. Turning Python into a
language so stupid a monkey could use it(there by slowing it down in
the process),is counter intuitive, and will chase away core followers.
Let Ruby try to include every way possible known to man to do one
simple process, just to please the most people. Are we Python coders
or "Corrupt Politicians" looking to grab every vote by trying to
please the masses thereby sacrificing our souls in the process -->
Ruby.

*It may be time to start hacking my own personal version of the Python
interpreter. hmm... Keep you ears to the ground...

 

[Steven D'Aprano]

C string formatting is short and a flexible enough, but it's out of
place in a language as high level as Python3. The new syntax allows more
flexibility, and it's better for most people that don't know C already,
like newbies, etc.

I'm somebody who frequently argues that we shouldn't assume that
everybody knows C. But on the other hand, we shouldn't assume that
newbies don't know C either! % formatting is so very common that even a
duffer like me who never learned C came to Python already knowing the
basics of % formatting.

 

[Steven D'Aprano]

So funny that now that Python 3.0 is actually released we have people
acting all surprised like they've never seen any of the new features in
Python 3.0 coming. However these features have been discussed for
years! And debated!

Debated by who? The entire Python-using community? Every single Python
programmer? Or just the small proportion of Python developers who are
also core developers?

Are you *really* surprised that some people had never heard of the
changes being debated until it was too late?

Personally the new string formatter is sorely needed in Python. And
they way it has been implemented is a thing of beauty. Basically the
burden of formatting strings has been moved from the print
statement/function to the objects themselves.

That's clearly not true. The print statement was not involved in
formatting strings in the past. From Python 2.5:
['s', 'p', 'a', 'm', ' ', 'a', 'n', 'd', ' ', 'e', 'g', 'g', 's']

No print required until well after the string substitution was completed.

Furthermore, the new {}
notation allows many, many more options for formatting to be used. Want
to display a floating point number with $#.## notation, and ($#.##) for
negative? It's all now possible. Couldn't be done before.

Of course it could be. You just needed to write your own formatting
engine. What you mean is that it couldn't be done with % formatting and
nothing else.

In short, this is a huge improvement, and backwards compatibility is
preserved for the 2.x style for those that wish it.

There clearly is a need for a more heavyweight formatting solution than %
and string.Template. There are things that can't be done easily with %
alone, and format() will make them much simpler. I have no objection to
the addition of the format() method (although I wonder whether it might
have been better as a function).

 

[Steven D'Aprano]

And lets not forget Python forcing of indention, that is Pythons
greatest strength!

Oh "r", haven't you heard? Python has braces too. Just start your code
with

from __future__ import braces


and see what happens.

 

[Steven D'Aprano]

It's not going to be removed for many years - if ever. The % string
formatting system is not deprecated in 3.0. For that very reason it must
stay until 3.2. We don't have plans to deprecate it in 3.1 so it will
stay at least until Python 3.3 which is to be released about 2014.

I am very glad to hear that.