Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

New Python 3.0 string formatting - really necessary?

903 views
Skip to first unread message

walterbyrd

unread,
Dec 19, 2008, 11:01:13 AM12/19/08
to
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'

unread,
Dec 19, 2008, 11:13:34 AM12/19/08
to

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.
>>> print("%s=%d" % ('this',99))
this=99


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

r

unread,
Dec 19, 2008, 11:54:51 AM12/19/08
to
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

unread,
Dec 19, 2008, 12:16:19 PM12/19/08
to
On Dec 19, 9:13 am, "Giampaolo Rodola'" <gne...@gmail.com> wrote:
> 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

unread,
Dec 19, 2008, 12:25:30 PM12/19/08
to pytho...@python.org
r wrote:
> 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

unread,
Dec 19, 2008, 12:27:27 PM12/19/08
to pytho...@python.org

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?

Jean-Paul Calderone

unread,
Dec 19, 2008, 12:38:14 PM12/19/08
to pytho...@python.org

What makes you think PyPy is going to enabling JIT'ing of Python 3 code?
Perhaps it will, someday, but I suspect it will provide a JIT for Python 2
long before.

Jean-Paul

r

unread,
Dec 19, 2008, 12:41:08 PM12/19/08
to
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!

bearoph...@lycos.com

unread,
Dec 19, 2008, 12:55:01 PM12/19/08
to
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

Christian Heimes

unread,
Dec 19, 2008, 1:10:59 PM12/19/08
to pytho...@python.org
walterbyrd schrieb:

> On Dec 19, 9:13 am, "Giampaolo Rodola'" <gne...@gmail.com> wrote:
>> 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'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.

Christian

Christian Heimes

unread,
Dec 19, 2008, 1:15:52 PM12/19/08
to pytho...@python.org
r schrieb:

> 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.

No, it's very powerful and used in other languages, too.

> What is the purpose of breaking backward compatibility just to write a
> print() function. This is going to push people away from python.

The purpose of a print() function has been discussed for at least 3
years. You are welcome to read up all dicussions.


> 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??

Wrong and wrong.
map stays but it has been turned into an iterator. The removal of lambda
has been discussed several years ago but it was repulsed. lambda stays.

> 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.

Python 3.0 is even more beautiful and more Pythonic. Backward
compatibility was broken for the sake of the language.

> 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!

Your truth turns to be a totally different truth than mine -- and most
of the active member of the community.

Christian

MRAB

unread,
Dec 19, 2008, 1:31:00 PM12/19/08
to pytho...@python.org
I would've hoped that Python 4000 would address the internals (JIT) just
as Python 3000 addressed the externals.

r

unread,
Dec 19, 2008, 1:44:25 PM12/19/08
to
~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

unread,
Dec 19, 2008, 2:43:12 PM12/19/08
to
On Dec 19, 11:01 am, walterbyrd <walterb...@iname.com> wrote:
>
> 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

unread,
Dec 19, 2008, 3:50:49 PM12/19/08
to
On Dec 19, 12:44 pm, r <rt8...@gmail.com> wrote:
> ~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

unread,
Dec 19, 2008, 4:10:12 PM12/19/08
to
On Fri, 19 Dec 2008 10:44:25 -0800, r wrote:

> ~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

Ben Finney

unread,
Dec 19, 2008, 4:41:56 PM12/19/08
to
Michael Torrie <tor...@gmail.com> writes:

> 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.

This doesn't describe a difference between Python 2.x and Python 3.0.
The string formatting in Python 2.x is nothing to do with ‘print’,
it's implemented in the function that handles the ‘%’ operator for
strings.

--
\ “If consumers even know there's a DRM, what it is, and how it |
`\ works, we've already failed.” —Peter Lee, Disney corporation, |
_o__) 2005 |
Ben Finney

Steve Holden

unread,
Dec 19, 2008, 5:45:37 PM12/19/08
to pytho...@python.org
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
--
Steve Holden +1 571 484 6266 +1 800 494 3119
Holden Web LLC http://www.holdenweb.com/

Scott David Daniels

unread,
Dec 19, 2008, 7:05:42 PM12/19/08
to
excord80 wrote:
> On Dec 19, 11:01 am, walterbyrd <walterb...@iname.com> wrote:
>> To me, it seems that this:
>> print "%s=%d" % ('this',99)
>> Is much easier, ...
>> This (if it's right) is much longer, ...

>> 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 `}').

Ah, but for internationalization, you can change the format
string to take args in a different order if, for example,
French messages want modifiers on one side and English on the other.
The code can stay the same, while only the text used to do the
formatting must change.

--Scott David Daniels
Scott....@Acm.Org

Aaron Brady

unread,
Dec 19, 2008, 7:59:53 PM12/19/08
to
On Dec 19, 1:43 pm, excord80 <excor...@gmail.com> wrote:
snip cons of Python

> 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

unread,
Dec 19, 2008, 8:12:00 PM12/19/08
to
Scott,
Oh, so Python 3.0 is an Equal Opportunity Enigma, now i get it :D

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

unread,
Dec 19, 2008, 8:46:13 PM12/19/08
to
On Fri, 19 Dec 2008 09:55:01 -0800, bearophileHUGS wrote:

> 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

Steven D'Aprano

unread,
Dec 19, 2008, 8:54:35 PM12/19/08
to
On Fri, 19 Dec 2008 10:25:30 -0700, Michael Torrie wrote:

> 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 = "%s and %s" % ("spam", "eggs")
>>> list(s)
['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

Steven D'Aprano

unread,
Dec 19, 2008, 8:54:43 PM12/19/08
to
On Fri, 19 Dec 2008 10:44:25 -0800, r wrote:

> 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

Steven D'Aprano

unread,
Dec 19, 2008, 9:07:33 PM12/19/08
to
On Fri, 19 Dec 2008 19:10:59 +0100, Christian Heimes wrote about %
formatting in Python 3:

> 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.


--
Steven

Carl Banks

unread,
Dec 19, 2008, 9:11:51 PM12/19/08
to
On Dec 19, 7:12 pm, r <rt8...@gmail.com> wrote:
> Marc,
> Why move away from a concise and widely accepted way of sting
> formatting, just to supposedly make it a little easier for n00bs?

You were the one that brought it up, chief. I doubt anyone is arguing
that this new formating was added just to make things easier for
newbies, we're just saying that your assertion that printf-style is
much easier for newbies is wrong.

If you care to, go read the rationale for this change PEP 3101. You'd
see the new formating was added to address limitations of the printf-
style. (Hint: the limitations aren't that %s, %d, and %f are hard to
remember.)


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

My friend, if you can't even cope with a new system of string
formating, do you really expect to be able to maintain your own hacked-
up fork of a highly wrought out programming language?


Carl Banks

Carl Banks

unread,
Dec 19, 2008, 9:16:09 PM12/19/08
to

I wish they would have at least deprecated or got rid of the %
operator, because that's ugly. There's no reason they couldn't have
added another method for printf-style formating, e.g.:

"The answer is %s.".sprintf("yes")


Carl Banks

Steven D'Aprano

unread,
Dec 19, 2008, 9:25:37 PM12/19/08
to
On Fri, 19 Dec 2008 16:05:42 -0800, Scott David Daniels wrote:

> Ah, but for internationalization, you can change the format string to
> take args in a different order if, for example, French messages want
> modifiers on one side and English on the other. The code can stay the
> same, while only the text used to do the formatting must change.

I can't see how this is any different between what we have now. Here's an
example using keyword arguments:

# untested
"{modifier} {noun}".format(modifier="dead", noun="parrot")
"{noun} {modifier}".format(modifier="mort", noun="perroquet")

compared to:

"%(modifier)s %(noun)s" % dict(modifier="dead", noun="parrot")
"%(noun)s %(modifier)s" % dict(modifier="mort", noun="perroquet")

Whether using % or format(), I don't see the need to change the code,
only the strings.

Using positional arguments is not really that different:

"{0} {1}".format("dead", "parrot")
"{0} {1}".format("perroquet", "mort")

versus:

"%s %s" % ("dead", "parrot")
"%s %s" % ("perroquet", "mort")

In this case, the template on the left remains the same, you just have to
reorder the string arguments on the right. Clearly less satisfactory than
the solution using keyword substitution, but whatever solution you pick,
I don't see any advantage to format() over % formatting. Can you show an
example?

--
Steven

r

unread,
Dec 19, 2008, 10:07:49 PM12/19/08
to
Thanks Steven,
We need a real Pepsi challenge here to show the insignificance of this
change. I am not against change. But when we lose something as -
compact- as %formating i'm going to want to see a damn good reason for
it! Especially when this breaks code, and the "French Connection" is
not good enough reason for me :)

Christian said this was not going to be depreciated until 3.2, but
that still puts the accepted way on the chopping block.

Steven D'Aprano

unread,
Dec 19, 2008, 10:07:49 PM12/19/08
to
On Fri, 19 Dec 2008 17:12:00 -0800, r wrote:

> 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!

Reading your wibbling, so do I. Take ten deep breaths and calm down.

Firstly, the introduction of format() is not to "make it a little easier
for n00bs" as you claim, but to allow more powerful, flexible string
formatting.

Secondly, to use % formatting to full effectiveness you need to know MUCH
more than (%s %f %d). You need to know:

Formatting codes: %s %r %d %f %g %G %c %i %u %o %x %X %e %E %%
(have I missed any?)
Keyword formatting: %(name)s
Flags: - + 0
Field width and precision, including the special case of "*"

and how they fit together:

%[(name)][flags][width][.precision][unused(!) length modifier]code


You also need to know about operator precedence:

>>> "%s" % 3+2
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
TypeError: cannot concatenate 'str' and 'int' objects

and the special casing of tuples:

>>> "Tuple = %s" % (1,2,3)
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
TypeError: not all arguments converted during string formatting

For trivial cases, format() isn't much harder than %:

"{0}".format(x)
"%s" % x

For more complex cases, format() will let you do things that you can't do
with only %, e.g. arbitrary fill characters, centring fields, percentage
formatting, mixing positional and keyword arguments, etc.

Before you blow yet another gasket, go read the PEP:

http://www.python.org/dev/peps/pep-3101/


--
Steven

Steven D'Aprano

unread,
Dec 19, 2008, 10:20:21 PM12/19/08
to
On Sat, 20 Dec 2008 01:54:35 +0000, Steven D'Aprano wrote:

> 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).

Except of course there is a format() function. Like len(), str() etc, it
just calls the appropriate special method on the argument:

format(obj, format_spec) -> obj.__format__(format_spec)


--
Steven

Steve Holden

unread,
Dec 19, 2008, 11:02:10 PM12/19/08
to Steven D'Aprano, pytho...@python.org
Steven D'Aprano wrote:
> On Fri, 19 Dec 2008 10:25:30 -0700, Michael Torrie wrote:
>
>> 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?
>
It isn't the least surprising that some people have been taken by
surprise by the changes. Neither is it surprising that some of them
don't like the changes that much. However, at least in the open source
world one has the *opportunity* to make one's voice heard and one's
opinion known, even thought he majority prefer to remain consumers of
the output of open source projects.

Where commercial projects are concerned the major influence one has is a
post-facto vote with one's wallet.

I hope, however, that those who don't like the changes but didn't bother
to track developments don't feel in any way disenfranchised. They are
still welcome to make their input, and of course there is nothing to
stop them keeping Python 2.X alive for as long as they wish.

[misconception about print's role]

>> 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).
>

That's doubtless a debate that will play for a long time, with no really
clear advantage either way. Programmers just like to debate these
things. Of course it's a trivial addition:

def format(s, *args, **kw):
return s.format(*args, **kw)

[I put **kw in becuase it's easier than checking the docs to se whether
keyword arguments are specified]. This doesn't mean there won't be
fifteen more posts on this thread about it.

Steve Holden

unread,
Dec 19, 2008, 11:02:10 PM12/19/08
to pytho...@python.org, pytho...@python.org
Steven D'Aprano wrote:
> On Fri, 19 Dec 2008 10:25:30 -0700, Michael Torrie wrote:
>
>> 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?
>
It isn't the least surprising that some people have been taken by
surprise by the changes. Neither is it surprising that some of them
don't like the changes that much. However, at least in the open source
world one has the *opportunity* to make one's voice heard and one's
opinion known, even thought he majority prefer to remain consumers of
the output of open source projects.

Where commercial projects are concerned the major influence one has is a
post-facto vote with one's wallet.

I hope, however, that those who don't like the changes but didn't bother
to track developments don't feel in any way disenfranchised. They are
still welcome to make their input, and of course there is nothing to
stop them keeping Python 2.X alive for as long as they wish.

[misconception about print's role]

>> 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).
>

Steve Holden

unread,
Dec 19, 2008, 11:04:58 PM12/19/08
to pytho...@python.org

If Python is so important to you it's a pity you haven't been playing
any active role in its development. Do you expect the developers to be
psychic?

rdmu...@bitdance.com

unread,
Dec 19, 2008, 11:27:46 PM12/19/08
to pytho...@python.org
Quoth Steven D'Aprano <st...@REMOVE-THIS-cybersource.com.au>:

> Whether using % or format(), I don't see the need to change the code,
> only the strings.
>
> Using positional arguments is not really that different:
>
> "{0} {1}".format("dead", "parrot")
> "{0} {1}".format("perroquet", "mort")

This should be something like:

_("{0} {1}").format(_("dead"), _("parrot"))

where il8n would substitute the template "{1} {0}" when doing French.

> versus:
>
> "%s %s" % ("dead", "parrot")
> "%s %s" % ("perroquet", "mort")
>
> In this case, the template on the left remains the same, you just have to
> reorder the string arguments on the right. Clearly less satisfactory than
> the solution using keyword substitution, but whatever solution you pick,
> I don't see any advantage to format() over % formatting. Can you show an
> example?

Not less satisfactory, but rather unworkable. You can't do proper il8n
with %s formatting, since there is no way for the il8n machinery to
reorder the argument tuple. It can only translate the template string.
So when doing il8n, the {} syntax wins out for brevity over the equivalent
% syntax (%s(somename)s).

Not that brevity is that important an argument. The new system is just
so much more flexible than the old. As someone else said, the design
is beautiful :) I have a couple thousand lines of python code I wrote
a while back to layer on a system with this kind of flexibility...I was
shocked and pleased when I saw the PEP, since it echoed so many of the
ideas I had implemented in that code, plus more. And all done better
of course :)

--RDM

r

unread,
Dec 20, 2008, 12:30:52 AM12/20/08
to
On Dec 19, 10:04 pm, Steve Holden <st...@holdenweb.com> wrote:
> r wrote:
> > Thanks Steven,
> > We need a real Pepsi challenge here to show the insignificance of this
> > change. I am not against change. But when we lose something as -
> > compact- as %formating i'm going to want to see a damn good reason for
> > it! Especially when this breaks code, and the "French Connection" is
> > not good enough reason for me :)
>
> > Christian said this was not going to be depreciated until 3.2, but
> > that still puts the accepted way on the chopping block.
>
> If Python is so important to you it's a pity you haven't been playing
> any active role in its development. Do you expect the developers to be
> psychic?

Steve,
I just recently started to have an opinion about these things. "The
squeaky wheel get the grease", just allowing my voice be heard. It
might seem that i am trashing Python dev, but that could not be
further from the truth.

Many great changes have been made in 3.0, i just feel strongly about C
style formating. Why could't we improve on what we had instead of
making radical changes? Thats all i am asking.

Stefan Behnel

unread,
Dec 20, 2008, 5:27:24 AM12/20/08
to
Steven D'Aprano wrote:
> I have no objection to
> the addition of the format() method (although I wonder whether it might
> have been better as a function).

I actually learned about the String.format() method in Java a while after
having read about str.format() in Python, and my first reaction was to
recognise how stupid you'd have to be to make that a static method that
ignores the string it's called on. :)

I think '...'.format() makes sense given that we already have '...'.join().

Stefan

Marc 'BlackJack' Rintsch

unread,
Dec 20, 2008, 6:14:31 AM12/20/08
to
On Fri, 19 Dec 2008 17:12:00 -0800, r wrote:

> 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!

Yeah, doomsday is near. Curly brackets and a number instead of a percent
sign followed by an 's' is a sure sign of the end…

You're a funny little troll, Sir.

Ciao,
Marc 'BlackJack' Rintsch

Steve Holden

unread,
Dec 20, 2008, 8:21:43 AM12/20/08
to pytho...@python.org
Stefan Behnel wrote:
[...]

> I think '...'.format() makes sense given that we already have '...'.join().
>
Sure it does, but that doesn't stop a lot of people disliking str.join()

Steve Holden

unread,
Dec 20, 2008, 8:25:53 AM12/20/08
to pytho...@python.org

I wasn't really a part of the decision-making process, but I anticipate
that the developers' reply would be that the new scheme is much more
adaptable, both to new data types (which can implement their own
__format__ method) and to internationalization (because it's possible to
alter word order in the format strings).

Thanks for clarifying your approach, by the way, which isn't as
unreasonable as it first seemed if you've only recently started using
Python. You will find over time that the developers are right about
these decisions much more than they are wrong, and you still have a
couple of years to get used to it ;-)

walterbyrd

unread,
Dec 20, 2008, 6:14:44 PM12/20/08
to
On Dec 19, 12:43 pm, excord80 <excor...@gmail.com> wrote:

> Also, I like having only *one* special symbol (`%') to worry
> about in my strings instead of two (`{' and `}').
>

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.

walterbyrd

unread,
Dec 20, 2008, 6:27:43 PM12/20/08
to
On Dec 19, 10:25 am, Michael Torrie <torr...@gmail.com> wrote:

> Personally the new string formatter is sorely needed in Python.  

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.

r

unread,
Dec 20, 2008, 6:34:27 PM12/20/08
to
Walter,

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

>>> s = 'python'
>>> n = 12
>>> f = 1.333333333
>>> '%s %05d %0.2f' %(s,n,f)
'python 00012 1.33'

i want to see how casting is handled. Thanks

walterbyrd

unread,
Dec 20, 2008, 6:36:46 PM12/20/08
to
On Dec 19, 10:55 am, bearophileH...@lycos.com wrote:

> Regarding the speed of Python3 programs,
> they will go faster

"The net result of the 3.0 generalizations is that Python 3.0 runs the
pystone benchmark around 10% slower than Python 2.5. "

http://docs.python.org/dev/3.0/whatsnew/3.0.html

> (Ruby programs are often slower
> than Python ones (because Ruby
> is a little higher level than Python)

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 am no expert on the subject, I am just going by stuff I have read on
web.

walterbyrd

unread,
Dec 20, 2008, 6:39:24 PM12/20/08
to
On Dec 20, 4:34 pm, r <rt8...@gmail.com> wrote:
> Walter,
>
> Would you be kind enough to translate this code to the new syntax?

I am sorry, but I just don't know the new syntax well enough. I am not
sure if the examples that I have posted, so far, are correct.

r

unread,
Dec 20, 2008, 6:44:47 PM12/20/08
to
Thanks, i understand. Maybe some of the pro "new syntax" guys will
show a translation

MRAB

unread,
Dec 20, 2008, 6:47:53 PM12/20/08
to pytho...@python.org
"{0}={1}".format(k, v) for k, v in params.items()

or:

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

r

unread,
Dec 20, 2008, 7:01:58 PM12/20/08
to
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

unread,
Dec 20, 2008, 7:05:41 PM12/20/08
to
In article
<b58f588a-e8db-41df...@w39g2000prb.googlegroups.com>,
walterbyrd <walte...@iname.com> wrote:

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

unread,
Dec 20, 2008, 7:11:43 PM12/20/08
to

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

unread,
Dec 20, 2008, 7:17:39 PM12/20/08
to pytho...@python.org
>>> '{0} {1:05} {2:.2}'.format(s, n, f)
'python 00012 1.3'

r

unread,
Dec 20, 2008, 7:20:38 PM12/20/08
to
On Dec 20, 6:05 pm, Roy Smith <r...@panix.com> wrote:
> In article
> <b58f588a-e8db-41df-a488-f7df62d56...@w39g2000prb.googlegroups.com>,

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

unread,
Dec 20, 2008, 7:27:22 PM12/20/08
to
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!

bearoph...@lycos.com

unread,
Dec 20, 2008, 8:05:55 PM12/20/08
to
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

unread,
Dec 20, 2008, 8:19:03 PM12/20/08
to
In article
<6b4176c3-49ce-4e7c...@s20g2000yqh.googlegroups.com>,
r <rt8...@gmail.com> wrote:

> 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

unread,
Dec 20, 2008, 8:28:15 PM12/20/08
to pytho...@python.org
r wrote:
> Thanks MRAB,
> except the float is not 2 decimal places, but its there
>
Oops!

>>> '{0} {1:05} {2:.2f}'.format(s, n, f)
'python 00012 1.33'
>>> '{0:s} {1:05d} {2:.2f}'.format(s, n, f)
'python 00012 1.33'

Steven D'Aprano

unread,
Dec 20, 2008, 8:38:35 PM12/20/08
to
On Sat, 20 Dec 2008 16:20:38 -0800, r wrote:

> On Dec 20, 6:05 pm, Roy Smith <r...@panix.com> wrote:

>> 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.

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

Steven D'Aprano

unread,
Dec 20, 2008, 8:49:45 PM12/20/08
to
On Sat, 20 Dec 2008 15:27:43 -0800, walterbyrd wrote:

> On Dec 19, 10:25 am, Michael Torrie <torr...@gmail.com> wrote:
>
>> Personally the new string formatter is sorely needed in Python.
>
> 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.

--
Steven

r

unread,
Dec 20, 2008, 8:54:09 PM12/20/08
to
On Dec 20, 7:38 pm, Steven D'Aprano <st...@REMOVE-THIS-

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

unread,
Dec 20, 2008, 8:55:35 PM12/20/08
to
On Dec 20, 7:38 pm, Steven D'Aprano <st...@REMOVE-THIS-
cybersource.com.au> wrote:
> 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:

>>> "%i %%i" % 0 % 1
'0 1'

So, just extend it. (Unproduced.)

>>> "%i %i" % 0 % 1
'0 1'
>>> "%r %i" % (2, 3, 4) % 1
'(2, 3, 4) 1'
>>> "%r %i" % (2, 3, 4)
'(2, 3, 4) %i'

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

Steven D'Aprano

unread,
Dec 20, 2008, 9:07:19 PM12/20/08
to
On Sat, 20 Dec 2008 16:01:58 -0800, r wrote:

> 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

Steven D'Aprano

unread,
Dec 20, 2008, 9:09:31 PM12/20/08
to
On Sat, 20 Dec 2008 17:54:09 -0800, r wrote:

> 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?


--
Steven

MRAB

unread,
Dec 20, 2008, 9:21:36 PM12/20/08
to pytho...@python.org
Interesting. The re module uses a form of bytecode. Not sure about the
relative cost of the dispatch code, though.

r

unread,
Dec 20, 2008, 9:23:00 PM12/20/08
to
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

unread,
Dec 20, 2008, 9:26:34 PM12/20/08
to
On Sat, 20 Dec 2008 17:55:35 -0800, Aaron Brady wrote:

> On Dec 20, 7:38 pm, Steven D'Aprano <st...@REMOVE-THIS-
> cybersource.com.au> wrote:
>> 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:
>
>>>> "%i %%i" % 0 % 1
> '0 1'
>
> So, just extend it. (Unproduced.)
>
>>>> "%i %i" % 0 % 1
> '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

Steven D'Aprano

unread,
Dec 20, 2008, 9:49:43 PM12/20/08
to
On Sat, 20 Dec 2008 18:23:00 -0800, r wrote:

> 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?

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.

--
Steven

MRAB

unread,
Dec 20, 2008, 9:49:57 PM12/20/08
to pytho...@python.org
A couple of problems:

1. How do you handle a literal '%'? If you just double up then you'll
need to fix the string after all your substitutions.

2. What if a substitution introduces a '%'?

I suppose a possible solution would be to introduce a special format
string, including a literal, eg:

f"%r %i" % (2, 3, 4) % 1

and then convert the result to a true string:

print(str(f"%r %i" % (2, 3, 4) % 1))

(although print() would call __str__ anyway).

The format string would track where the last substitution occurred.

Hmm... I think I'll just learn the new method. :-)

walterbyrd

unread,
Dec 21, 2008, 12:11:16 AM12/21/08
to
On Dec 20, 5:05 pm, Roy Smith <r...@panix.com>

> He got really hung up on the % syntax.

I guess it's good to know that there is, at least, one person in the
world doesn't like the % formatting. As least the move was not
entirely pointless.

But, you must admit, of all the things people complain about with
Python, the % formatting is probably one of the least common
complaints. Complaints about Python's speed seem much more common.

Yet, 3.0 makes the speed worse, and "fixes" a non-problem.

I can see where the new formatting might be helpful in some cases.
But, I am not sure it's worth the cost.

Kay Schluehr

unread,
Dec 21, 2008, 1:13:49 AM12/21/08
to
On 20 Dez., 02:54, Steven D'Aprano <st...@REMOVE-THIS-
cybersource.com.au> wrote:

> 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?

"If I'd asked people what they wanted, they would have asked for a
better horse."

Henry Ford

r

unread,
Dec 21, 2008, 1:15:23 AM12/21/08
to

This all really comes down to the new python users. Yea, i said it.
Not rabid fanboys like Steven and myself.(i can't speak for walter but
i think he would agree) Are we going to make sure joe-blow python
newbie likes the language. And doesn't get turned off and run over to
ruby or whoever. Like it or not, without newusers python is doomed to
the same fate as all the other "great" languages who had their 15 mins
of fame.

We must proactively seek out the wants of these new users and make
sure python stays alive. But we also must not sell are pythonic souls
in the process.

It would be nice to get a vote together and see what does the average
pythoneer want? What do they like, What do they dislike. What is the
state of the Python Union? Does anybody know, Does anybody care? I
think python is slipping away from it's dominate foothold on the
world. Google's use of python may be the only thing holding this house
of cards together. Ruby's "hype" is defiantly growing and unless we
strive for greatness, python may fail. I think ruby may have their act
together a little better than us right now. And since Ruby is such a
hodge-podge of different languages, the __init__ hold is there for
many.

what does joe-python want???

Patrick Mullen

unread,
Dec 21, 2008, 3:57:46 AM12/21/08
to pytho...@python.org
On Sat, Dec 20, 2008 at 10:15 PM, r <rt8...@gmail.com> wrote:
> On Dec 20, 11:11 pm, walterbyrd <walterb...@iname.com> wrote:
>> On Dec 20, 5:05 pm, Roy Smith <r...@panix.com>
>>
>> > He got really hung up on the % syntax.
>>
>> I guess it's good to know that there is, at least, one person in the
>> world doesn't like the % formatting. As least the move was not
>> entirely pointless.
>>
>> But, you must admit, of all the things people complain about with
>> Python, the % formatting is probably one of the least common
>> complaints. Complaints about Python's speed seem much more common.
>>
>> Yet, 3.0 makes the speed worse, and "fixes" a non-problem.

A few points:
1) The new formatting is NOT the reason for the speed slowdown. So
this change at least was a no cost change. No cost to interpreter
speed, and no cost as it doesn't replace the old sprintf style. Of
all the things to complain about in python 3.0, the format method is
the silliest.
2) In my experience, major version changes tend to be slower than
before. When a lot of things change, especially if very low-level
things change, as happened in python 3.0, the new code has not yet
went through many years of revision and optimization that the old code
has. In my opinion, python 3 was rushed out the door a bit. It could
have done with a few more months of optimization and polishing.
However, on the other hand, it is going to take so long for python
infrastructure to convert to python 3, that an earlier release makes
sense, even if it hasn't been excessively polished. The biggest
reason for the speed change is the rewritten stdio and
unicode-everything. Hopefully this stuff can be improved in future
updates. I don't think anyone WANTS cpython to be slower.

Marc 'BlackJack' Rintsch

unread,
Dec 21, 2008, 4:35:22 AM12/21/08
to
On Sat, 20 Dec 2008 22:15:23 -0800, r wrote:

> It would be nice to get a vote together and see what does the average
> pythoneer want? What do they like, What do they dislike. What is the
> state of the Python Union? Does anybody know, Does anybody care? I think
> python is slipping away from it's dominate foothold on the world.
> Google's use of python may be the only thing holding this house of cards
> together. Ruby's "hype" is defiantly growing and unless we strive for
> greatness, python may fail. I think ruby may have their act together a
> little better than us right now. And since Ruby is such a hodge-podge of
> different languages, the __init__ hold is there for many.
>
> what does joe-python want???

That's not completely irrelevant but I think one of Python's strength is
that we have a BDFL who decides carefully what he thinks is best for the
language instead of integrating every random idea some newbie comes up
with and which might sound useful at first sight.

Python has its quirks but even with things I don't like I often realize
later it was a wise decision that integrates well into the language
whereas my ideas for "fixes" of the quirks wouldn't. "joe-python" most
often doesn't see the whole picture and demands changes that look easy at
first sight, but are hard to implement right and efficient or just shifts
the problem somewhere else where the next "joe-python" trips over it.

Ciao,
Marc 'BlackJack' Rintsch

Marc 'BlackJack' Rintsch

unread,
Dec 21, 2008, 4:42:47 AM12/21/08
to
On Sat, 20 Dec 2008 15:27:43 -0800, walterbyrd wrote:

> On Dec 19, 10:25 am, Michael Torrie <torr...@gmail.com> wrote:
>
>> Personally the new string formatter is sorely needed in Python.
>
> 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.

Many newbie code I have seen avoids it by string concatenation:

greeting = 'Hello, my name is ' + name + ' and I am ' + str(age) + ' old.'

That's some kind of indirect complaint. :-)

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

And even if nobody has problems with the limitations of ``%`` string
formatting why shouldn't they add a more flexible and powerful way!?
Python 3.0 is not a bug fix release.

Ciao,
Marc 'BlackJack' Rintsch

Steven D'Aprano

unread,
Dec 21, 2008, 5:14:24 AM12/21/08
to
On Sun, 21 Dec 2008 00:57:46 -0800, Patrick Mullen wrote:

> 2) In my experience, major version changes tend to be slower than
> before. When a lot of things change, especially if very low-level
> things change, as happened in python 3.0, the new code has not yet went
> through many years of revision and optimization that the old code has.


I was around for the change from Python 1.5 -> 2.x. By memory, I skipped
a couple of versions... I think I didn't make the move until Python 2.2
or 2.3 was released. Python 2.0 was significantly slower than 1.5 in a
number of critical areas, but not for long.

Actually, it's quite possible that Python 1.5 is still faster than Python
2.x in some areas -- but of course it misses a lot of features, and at
the end of the day, the difference between your script completing in 0.03
seconds or in 0.06 seconds is meaningless.


> In my opinion, python 3 was rushed out the door a bit. It could have
> done with a few more months of optimization and polishing. However, on
> the other hand, it is going to take so long for python infrastructure to
> convert to python 3, that an earlier release makes sense, even if it
> hasn't been excessively polished. The biggest reason for the speed
> change is the rewritten stdio and unicode-everything. Hopefully this
> stuff can be improved in future updates. I don't think anyone WANTS
> cpython to be slower.

I understand that the 3.0.1 release due out around Christmas will have
some major speed-ups in stdio.


--
Steven

Aaron Brady

unread,
Dec 21, 2008, 6:23:43 AM12/21/08
to
On Dec 20, 8:26 pm, Steven D'Aprano <st...@REMOVE-THIS-

cybersource.com.au> wrote:
> On Sat, 20 Dec 2008 17:55:35 -0800, Aaron Brady wrote:
snip

> > This behavior is currently legal:
>
> >>>> "%i %%i" % 0 % 1
> > '0 1'
>
> > So, just extend it.  (Unproduced.)
>
> >>>> "%i %i" % 0 % 1
> > '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.

No, it's not part of the (new) '%' operation. '%' handles one flag at
a time. It's not an error if the author intends it.

> "%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'

Anything, so long as it's (contraction) consistent and general.

> 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.

Leave that to unit testing and your QA team.

To make the change, the burden of proof (which is large) would fall to
me. However, in the abstract case, it's not clear that either one is
favorable, more obvious, or a simpler extrapolation.

Bug-proneness is an argument against a construction, just not a
conclusive one. How heavy is it in this case?

Aaron Brady

unread,
Dec 21, 2008, 6:37:50 AM12/21/08
to

Now that I'm fighting 'r's war for him/her...

Um, here's one possibility. On the first interpolation, flags are
noted and stored apart from subsequent interpolations. Then, use a
sentinel to terminate the interpolation. (Unproduced.)

>>> "%r %i" % ( 2, 3 ) % 0
'(2, 3) 0'
>>> "%% %r" % ( 2, 3 ) % str.interp_end
'% (2, 3)'
>>> "%sss%i" % "%d" % 0
'%dss0'

The first %s is replaced with %d, but doesn't hijack the '0'. If you
want to interpolate the %d, use the sentinel. The sentinel is what
causes '%%' to be handled.

>>> "%sss%i" % "%d" % 0 % 1
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
TypeError: not all arguments converted during string formatting
>>> "%sss%i" % "%d" % 0 % str.interp_end % 1
'1ss0'

Treating tuples as a special case appears to be the simpler solution,
but this, 'chaining', to adopt the term, is still feasible.

Duncan Booth

unread,
Dec 21, 2008, 7:45:32 AM12/21/08
to
Steven D'Aprano <st...@REMOVE-THIS-cybersource.com.au> wrote:

> 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.
>

You seem to have made an unwarranted assumption, namely that a binary
operator has to compile to a function with two operands. There is no
particular reason why this has to always be the case: for example, I
believe that C# when given several strings to add together optimises this
into a single call to a concatenation method.

Python *could* do something similar if the appropriate opcodes/methods
supported more than two arguments:

a+b+c+d might execute a.__add__(b,c,d) allowing more efficient string
concatenations or matrix operations, and a%b%c%d might execute as
a.__mod__(b,c,d).

In that alternate universe your example:

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

simply throws "TypeError: not enough arguments for format string", and

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

just converts the tuple as a single argument. It also provides the answer
to how you put a percent in the format string (double it) and what happens
if a substitution inserts a percent (it doesn't interact with the
formatting operators).

Marc 'BlackJack' Rintsch

unread,
Dec 21, 2008, 8:34:35 AM12/21/08
to
On Sun, 21 Dec 2008 12:45:32 +0000, Duncan Booth wrote:

> You seem to have made an unwarranted assumption, namely that a binary
> operator has to compile to a function with two operands. There is no
> particular reason why this has to always be the case: for example, I
> believe that C# when given several strings to add together optimises
> this into a single call to a concatenation method.
>
> Python *could* do something similar if the appropriate opcodes/methods
> supported more than two arguments:
>
> a+b+c+d might execute a.__add__(b,c,d) allowing more efficient string
> concatenations or matrix operations, and a%b%c%d might execute as
> a.__mod__(b,c,d).

But that needs special casing strings and ``%`` in the comiler, because
it might not be always safe to do this on arbitrary objects. Only in
cases where the type of `a` is known at compile time and ``a % b``
returns an object of ``type(a)``.

Ciao,
Marc 'BlackJack' Rintsch

Steven D'Aprano

unread,
Dec 21, 2008, 8:52:27 AM12/21/08
to
On Sun, 21 Dec 2008 12:45:32 +0000, Duncan Booth wrote:

> Steven D'Aprano <st...@REMOVE-THIS-cybersource.com.au> wrote:
>
>> 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.
>>
> You seem to have made an unwarranted assumption, namely that a binary
> operator has to compile to a function with two operands. There is no
> particular reason why this has to always be the case: for example, I
> believe that C# when given several strings to add together optimises
> this into a single call to a concatenation method.

[...]

> Python *could* do something similar if the appropriate opcodes/methods
> supported more than two arguments:
>
> a+b+c+d might execute a.__add__(b,c,d) allowing more efficient string
> concatenations or matrix operations, and a%b%c%d might execute as
> a.__mod__(b,c,d).

That's only plausible if the operations are associative. Addition is
associative, but string interpolation is not:

>>> "%%%s" % ("%s" % "b")
'%b'
>>> ("%%%s" % "%s") % "b"


Traceback (most recent call last):
File "<stdin>", line 1, in <module>
TypeError: not all arguments converted during string formatting

Since string interpolation isn't associative, your hypothetical __mod__
method might take multiple arguments, but it would have to deal with them
two at a time, unlike concatenation where the compiler could do them all
at once. So whether __mod__ takes two arguments or many is irrelevant:
its implementation must rely on some other function which takes two
arguments and must succeed or fail on that.

Either that, or we change the design of % interpolation, and allow it to
silently ignore errors. I assumed that is what Aaron wanted.



> In that alternate universe your example:
>
> "%i %i %i %i" % 5 % 3 %7
>
> simply throws "TypeError: not enough arguments for format string"

That has a disturbing consequence.

Consider that most (all?) operations, we can use temporary values:

x = 1 + 2 + 3 + 4
=> x == 10

gives the same value for x as:

temp = 1 + 2 + 3
x = temp + 4

I would expect that the same should happen for % interpolation:

# using Aaron's hypothetical syntax
s = "%s.%s.%s.%s" % 1 % 2 % 3 % 4
=> "1.2.3.4"

should give the same result as:

temp = "%s.%s.%s.%s" % 1 % 2 % 3
s = temp % 4

But you're arguing that the first version should succeed and the second
version, using a temporary value, should fail. And that implies that if
you group part of the expression in parentheses, it will fail as well:

s = ("%s.%s.%s.%s" % 1 % 2 % 3) % 4

Remove the parentheses, and it succeeds. That's disturbing. That makes
the % operator behave very differently from other operators.

Note that with the current syntax, we don't have that problem: short-
supplying arguments leads to an exception no matter what.


> "%s" % (1,2,3)
>
> just converts the tuple as a single argument. It also provides the
> answer to how you put a percent in the format string (double it)

I trust you know that already works, but just in case:

>>> "%g%%" % 12.5
'12.5%'

> and what happens if a substitution inserts a percent (it doesn't
> interact with the formatting operators).

Ditto:

>>> "%s" % "%g"
'%g'

--
Steven

Steve Holden

unread,
Dec 21, 2008, 9:50:16 AM12/21/08
to pytho...@python.org
r wrote:
> On Dec 20, 11:11 pm, walterbyrd <walterb...@iname.com> wrote:
>> On Dec 20, 5:05 pm, Roy Smith <r...@panix.com>
>>
>>> He got really hung up on the % syntax.
>> I guess it's good to know that there is, at least, one person in the
>> world doesn't like the % formatting. As least the move was not
>> entirely pointless.
>>
>> But, you must admit, of all the things people complain about with
>> Python, the % formatting is probably one of the least common
>> complaints. Complaints about Python's speed seem much more common.
>>
>> Yet, 3.0 makes the speed worse, and "fixes" a non-problem.
>>
>> I can see where the new formatting might be helpful in some cases.
>> But, I am not sure it's worth the cost.
>
> This all really comes down to the new python users. Yea, i said it.
> Not rabid fanboys like Steven and myself.(i can't speak for walter but
> i think he would agree) Are we going to make sure joe-blow python
> newbie likes the language. And doesn't get turned off and run over to
> ruby or whoever. Like it or not, without newusers python is doomed to
> the same fate as all the other "great" languages who had their 15 mins
> of fame.
>
> We must proactively seek out the wants of these new users and make
> sure python stays alive. But we also must not sell are pythonic souls

that's "our" (possessive), r, not "are" (verb)


> in the process.
>
> It would be nice to get a vote together and see what does the average
> pythoneer want? What do they like, What do they dislike. What is the
> state of the Python Union? Does anybody know, Does anybody care? I
> think python is slipping away from it's dominate foothold on the
> world. Google's use of python may be the only thing holding this house
> of cards together. Ruby's "hype" is defiantly growing and unless we
> strive for greatness, python may fail. I think ruby may have their act
> together a little better than us right now. And since Ruby is such a
> hodge-podge of different languages, the __init__ hold is there for
> many.
>
> what does joe-python want???

Don't make the mistake of assuming there is a "Joe Python" whose needs
neatly encapsulate the sum of all Python users' needs. There's plenty of
evidence from this group that different people like, want or need
different things from Python, and attempting to measure user
requirements by democratic means is not likely to produce much useful
information.

There is no such thing as "the average Python programmer": an average
can only be measured for one-dimensional values on some sort of linear
continuum. Python users live in a multi-dimensional space where the
concept of an average has little meaning and less use.

As for your assertion that Google's use of Python may be the only thing
maintaining Python's popularity, it's complete twaddle. Take a look
around at who's involved in using Python. I suspect Industrial Light and
Magic ,may have more Python programmers than Google, who also make
extensive use of Java and one other language (C++?), as well as a bevy
of others as justified by project needs. Rackspace, NASA, Canonical and
many others are keen supporters of the language, and they put their
money where their mouths are by incorporating it into their products.

regards
Steve
--
Steve Holden +1 571 484 6266 +1 800 494 3119
Holden Web LLC http://www.holdenweb.com/

sk...@pobox.com

unread,
Dec 21, 2008, 9:59:53 AM12/21/08
to Marc 'BlackJack' Rintsch, pytho...@python.org

Marc> Many newbie code I have seen avoids it by string concatenation:

Marc> greeting = 'Hello, my name is ' + name + ' and I am ' + str(age) + ' old.'

Marc> That's some kind of indirect complaint. :-)

I see Python code like that written by people with a C/C++ background. I
don't think you can necessarily chalk that up to %-string avoidance. They
learn that + will concatenate two strings and don't look further.

--
Skip Montanaro - sk...@pobox.com - http://smontanaro.dyndns.org/

Duncan Booth

unread,
Dec 21, 2008, 10:30:34 AM12/21/08
to
Steven D'Aprano <st...@REMOVE-THIS-cybersource.com.au> wrote:

>> a+b+c+d might execute a.__add__(b,c,d) allowing more efficient string
>> concatenations or matrix operations, and a%b%c%d might execute as
>> a.__mod__(b,c,d).
>
> That's only plausible if the operations are associative. Addition is
> associative, but string interpolation is not:

Addition is not associative on arbitrary types.

>
>>>> "%%%s" % ("%s" % "b")
> '%b'
>>>> ("%%%s" % "%s") % "b"
> Traceback (most recent call last):
> File "<stdin>", line 1, in <module>
> TypeError: not all arguments converted during string formatting
>
> Since string interpolation isn't associative, your hypothetical
> __mod__ method might take multiple arguments, but it would have to
> deal with them two at a time, unlike concatenation where the compiler
> could do them all at once. So whether __mod__ takes two arguments or
> many is irrelevant: its implementation must rely on some other
> function which takes two arguments and must succeed or fail on that.

I don't see that. What I suggested was that a % b % c would map to
a.__mod__(b,c). (a % b) % c would also map to that, but a % (b % c) could
only possibly map to a.__mod__(b.__mod__(c))

Duncan Booth

unread,
Dec 21, 2008, 10:30:34 AM12/21/08
to
Marc 'BlackJack' Rintsch <bj_...@gmx.net> wrote:

>> a+b+c+d might execute a.__add__(b,c,d) allowing more efficient string
>> concatenations or matrix operations, and a%b%c%d might execute as
>> a.__mod__(b,c,d).
>
> But that needs special casing strings and ``%`` in the comiler, because
> it might not be always safe to do this on arbitrary objects. Only in
> cases where the type of `a` is known at compile time and ``a % b``
> returns an object of ``type(a)``.
>

I could be wrong, but I don't see that would be the case.

I think it would be safe (in this hypothetical universe) any time that 'a'
had a method __mod__ which accepted more than one argument.

It might be simpler if I'd suggested an imaginary __mmod__ method so the
opcode for multiple-mod could check for that method or fall back to doing
mod of the first two values and then mmod of the result and any remaining
values until only two remain.

Aaron Brady

unread,
Dec 21, 2008, 10:40:25 AM12/21/08
to

'x+y' makes no guarantees whatsoever. It could return an object of
type(x), type(y), or neither. 'a%b' in the case of strings is just,
str.__mod__, returning string.

In a+b+c, 'a' gets dibs over what the rest see, so there's no more
danger in the multi-ary case, than in binary; and that hasn't stopped
us before.

You might be confusing the cases of arbitrary operators vs. uniform
operators. 'a' does not get dibs in 'a+b*c'; 'b*c' are allowed to
carry out their affairs. But in 'a+b+c', 'a*b*c', 'a%b%c', and so on,
'a' has final say on b's and c's behaviors via its return value, so
loses nothing by combining such a call.

In short, you can force it anyway, so it's syntactic sugar after that.

Aaron Brady

unread,
Dec 21, 2008, 10:57:12 AM12/21/08
to
On Dec 21, 8:50 am, Steve Holden <st...@holdenweb.com> wrote:
> r wrote:
snip

You've confused dimensions with modes. There is such thing as the
center of a bivariate distribution--- it is merely the most common of
the individual variables, the top of a 3-D hill, or the center of
mass.

However, an average only makes sense for unimodal distributions. If
the distribution is bi-modal, there's no "average" in the neat sense.

Dollars earned per hour spent writing in Python is a good candidate.
There are two modes in that distribution. One at 0, the other in the
tens or hundreds. And the global average is less common than either
mode individually. So in this case, we have one "Joe Py" for every
mode: Joe Free Py, and Joe Paid Py. (You might actually get multi-
modal on that one-- Joe Salary Py, Joe Wage Py, Joe Stipend Py, Joe
Free Py, but $0.01/hr. is less common than 0, and less common than
$50.)

You might also argue that the standard deviation is so high as to make
any one data point unrepresentative of many others. But if you have
variables in two dimensions, they're independent by definition (or
there exists a basis set that is).

Mel

unread,
Dec 21, 2008, 11:06:51 AM12/21/08
to
Duncan Booth wrote:

> I don't see that. What I suggested was that a % b % c would map to
> a.__mod__(b,c). (a % b) % c would also map to that, but a % (b % c) could
> only possibly map to a.__mod__(b.__mod__(c))

There's a compiling problem here, no? You don't want a%b%c to implement as
a.__mod__(b,c) if a is a number.

Mel.

Marc 'BlackJack' Rintsch

unread,
Dec 21, 2008, 11:09:04 AM12/21/08
to
On Sun, 21 Dec 2008 15:30:34 +0000, Duncan Booth wrote:

> Marc 'BlackJack' Rintsch <bj_...@gmx.net> wrote:
>
>>> a+b+c+d might execute a.__add__(b,c,d) allowing more efficient string
>>> concatenations or matrix operations, and a%b%c%d might execute as
>>> a.__mod__(b,c,d).
>>
>> But that needs special casing strings and ``%`` in the comiler, because
>> it might not be always safe to do this on arbitrary objects. Only in
>> cases where the type of `a` is known at compile time and ``a % b``
>> returns an object of ``type(a)``.
>>
> I could be wrong, but I don't see that would be the case.
>
> I think it would be safe (in this hypothetical universe) any time that
> 'a' had a method __mod__ which accepted more than one argument.

And returns an object of ``type(a)`` or at least a "duck type" so that it
is guaranteed that ``a.__mod__(b, c)`` really has the same semantics as
``a.__mod__(b).__mod__(c)``. For arbitrary objects `a`, `b`, and `c`
that are not known at compile time, how could the compiler decide if it
is safe to emit code that calls `a.__mod__()` with multiple arguments?

Ciao,
Marc 'BlackJack' Rintsch

MRAB

unread,
Dec 21, 2008, 11:31:51 AM12/21/08
to pytho...@python.org
A possible solution occurred to me shortly after I posted, but I decided
that sleep was more important. :-)

The original format is a string. The result of '%' is a string if
there's only 1 placeholder to fill, or a (partial) format object (class
"Format"?) if there's more than one. Similarly, the format object
supports '%'. The result of '%' is a string if there's only 1
placeholder to fill, or a new (partial) format object if there's more
than one.

>>> f = "%r %i"
>>> type(f)
<type 'str'>
>>> f = f % (2, 3, 4)
>>> type(f)
<type 'Format'>
>>> f = f % 1
>>> type(f)
<type 'str'>

Aaron Brady

unread,
Dec 21, 2008, 11:41:35 AM12/21/08
to

Alright, so how are you handling:

>>> f= "%s %i"
>>> type( f )
<type 'str'>
>>> f= f% '%i' #now '%i %i'
>>> type( f )
<type 'Format'>
>>> f= f% 1
>>> type( f )
?

In other words, are you slipping '1' in to the very first available
slot, or the next, after the location of the prior?

MRAB

unread,
Dec 21, 2008, 11:58:53 AM12/21/08
to pytho...@python.org
Let's assume that Format objects display their value like the equivalent
string format:

>>> f = "%r %i"
>>> f
'%r %i'


>>> f = f % (2, 3, 4)

>>> f
<Format '(2, 3, 4) %i'>


>>> f = f % 1

>>> f
'(2, 3, 4) 1'
>>>
>>> f = "%s %i"
>>> f
'%s %i'
>>> f = f % '%i'
>>> f
<Format '%%i %i'>


>>> f = f % 1

>>> f
'%%i 1'

bearoph...@lycos.com

unread,
Dec 21, 2008, 12:51:58 PM12/21/08
to
MRAB:
> Interesting. The re module uses a form of bytecode. Not sure about the
> relative cost of the dispatch code, though.

I was talking about the main CPython VM, but the same ideas may be
adapted for the RE engine too.

Bye,
bearophile

Christian Heimes

unread,
Dec 21, 2008, 2:01:12 PM12/21/08
to pytho...@python.org
Patrick Mullen schrieb:

> 2) In my experience, major version changes tend to be slower than
> before. When a lot of things change, especially if very low-level
> things change, as happened in python 3.0, the new code has not yet
> went through many years of revision and optimization that the old code
> has. In my opinion, python 3 was rushed out the door a bit. It could

> have done with a few more months of optimization and polishing.
> However, on the other hand, it is going to take so long for python
> infrastructure to convert to python 3, that an earlier release makes
> sense, even if it hasn't been excessively polished. The biggest
> reason for the speed change is the rewritten stdio and
> unicode-everything. Hopefully this stuff can be improved in future
> updates. I don't think anyone WANTS cpython to be slower.

The 3.0 release targets third party developers. Authors of 3rd party
extensions and libraries need a stable API to port their software to a
new major release. The main objective was feature completeness and
stability. If you need speed either stick to the 2.x series or wait
until 3.1 is out.

We could have waited a few more months or even a few more years with a
3.0 release. There is always - I repeat ALWAYS - work to do. For an open
source project like Python "release early, release often" works better.

Christian

r

unread,
Dec 21, 2008, 2:26:02 PM12/21/08
to
I noticed when i mentioned "self" nobody wants to touch that subject.
There could be many reasons why...

0.) nobody but the 10 regulars i see here exists
1.) nobody cares(doubt it)
2.) nobody is brave enough to question it(maybe)
3.) most people like to type self over and over again(doubt it)
4.) most people here have given up on changing the BDFL's mind about
it. (good possibility)
5.) this is a hot-button topic(no doubt in my mind!)

I think Guido's intension's are pure, but this is a major turnoff to
new users. Do we really need to hold a new users hand that much. Does
it really matter if they know the path of said obj. If you can't
fiqure this out for yourself you have much greater problems.

I do not like self, and i lamented it from day one, now it is second
nature to me but does that mean it is really needed?? I feel i have
been brainwashed into its usage.

This was the reason for using indention over the bracket plague in
python. REDUNDANCY!!! Why not dump self and make the language cleaner.
I love python's classes, but HATE self.redundant! This really needs to
be fixed, and you have not heard the last from me about it!!!

3000 would have been the perfect time to dump self and really clean up
the language, and it's not too late, dawn is not upon us yet.

sk...@pobox.com

unread,
Dec 21, 2008, 2:53:06 PM12/21/08
to r, pytho...@python.org

r> I do not like self, and i lamented it from day one, now it is second
r> nature to me but does that mean it is really needed?? I feel i have
r> been brainwashed into its usage.

...

r> 3000 would have been the perfect time to dump self and really clean up
r> the language, and it's not too late, dawn is not upon us yet.

Bruce Eckel proposes removing self from argument lists:

http://www.artima.com/weblogs/viewpost.jsp?thread=239003

Guido responds:

http://neopythonic.blogspot.com/2008/10/why-explicit-self-has-to-stay.html

Luis Zarrabeitia

unread,
Dec 21, 2008, 2:54:55 PM12/21/08
to r, pytho...@python.org

Quoting r <rt8...@gmail.com>:

> I noticed when i mentioned "self" nobody wants to touch that subject.
> There could be many reasons why...
>
> 0.) nobody but the 10 regulars i see here exists
> 1.) nobody cares(doubt it)
> 2.) nobody is brave enough to question it(maybe)
> 3.) most people like to type self over and over again(doubt it)
> 4.) most people here have given up on changing the BDFL's mind about
> it. (good possibility)
> 5.) this is a hot-button topic(no doubt in my mind!)

You forgot
6.) it is the best, cleanest, most consistent and extensible way to do it.



> This was the reason for using indention over the bracket plague in
> python. REDUNDANCY!!! Why not dump self and make the language cleaner.
> I love python's classes, but HATE self.redundant! This really needs to
> be fixed, and you have not heard the last from me about it!!!

Do you also hate cls.redundant on a classmethod? Would you rather type 'self'
even when it is referring to a class? Would you like to resort to a hack, like
C#3.0's 'this' explicit argument, when monkey-patching?

I used to hate 'self'. Then I met classmethods, metaclasses and decorators, and
the 'new'/'types' modules. It's just one of those examples where Guido's time
machine works flawlessly.

> 3000 would have been the perfect time to dump self and really clean up
> the language, and it's not too late, dawn is not upon us yet.

No need to wait for python 3000.

You can have a 'selfless metaclass' right now:

http://www.voidspace.org.uk/python/articles/metaclasses.shtml

(BTW, I really hope you are complaining about the explicit self on the argument
list, and not about the 'self.' prefix - if that were the case, what magic would
you propose for the compiler to guess when you are referring to locals, globals,
class or instance variables?)


--
Luis Zarrabeitia
Facultad de Matemática y Computación, UH
http://profesores.matcom.uh.cu/~kyrie


MRAB

unread,
Dec 21, 2008, 2:55:14 PM12/21/08
to pytho...@python.org
r wrote:
> I noticed when i mentioned "self" nobody wants to touch that subject.
> There could be many reasons why...
>
> 0.) nobody but the 10 regulars i see here exists
> 1.) nobody cares(doubt it)
> 2.) nobody is brave enough to question it(maybe)
> 3.) most people like to type self over and over again(doubt it)
> 4.) most people here have given up on changing the BDFL's mind about
> it. (good possibility)
> 5.) this is a hot-button topic(no doubt in my mind!)
>
6.) nobody here wants to go through that whole discussion yet again

Patrick Mullen

unread,
Dec 21, 2008, 2:56:25 PM12/21/08
to pytho...@python.org
On Sun, Dec 21, 2008 at 11:26 AM, r <rt8...@gmail.com> wrote:
> I noticed when i mentioned "self" nobody wants to touch that subject.
> There could be many reasons why...
>
> 0.) nobody but the 10 regulars i see here exists
> 1.) nobody cares(doubt it)
> 2.) nobody is brave enough to question it(maybe)
> 3.) most people like to type self over and over again(doubt it)
> 4.) most people here have given up on changing the BDFL's mind about
> it. (good possibility)
> 5.) this is a hot-button topic(no doubt in my mind!)

It's a combination between (4) (5) and (6). 6 being, we have
discussed "self" every week for the past 6 years, it hasn't changed
yet, it's not going away, it's not a trivial "problem", deal with it.

(0) is ridiculous, there are more than 10 respondents to this post alone.
(1) - if nobody cared it wouldn't come up every week, but it's been
discussed so much most are tired of it
(2) - people question it all the time, usually people who are new to
the language but not always. The discussion generally doesn't amount
to anything
(3) - It's not about wanting to type self over and over again, it's
about being able to start with functions or start with classes, and
easily refactor to the other way when needed; and never having a
chance to wonder where a variable came from. There are ups and downs
to self, it is generally more work to remove it than it is worth, what
would the gain be? We'd be trading some ups and downs for some other
ups and downs. And no, BDFL is not going to bend on self. He almost
bent on the issue a few weeks ago, but his proposition merely changed
some syntax - self was still there.

On Sun, Dec 21, 2008 at 11:01 AM, Christian Heimes <li...@cheimes.de> wrote:
> We could have waited a few more months or even a few more years with a
> 3.0 release. There is always - I repeat ALWAYS - work to do. For an open
> source project like Python "release early, release often" works better.

Good point, and I agree. It's too early for people to complain about
python 3 being
slow. It's also too both too late and too early to complain about
things in python 3
that are thought of as a step backward. It's too late, because python
3 is out and
it's already been changed! Things are not going to change back. Complaints are
a bit useless at this point, except to let off steam. It's too early,
because without
using python3 in a major project, from the ground up, with the new features,
the benefits or negatives for all of the changes cannot truly be known.

Bruno Desthuilliers

unread,
Dec 21, 2008, 2:14:49 PM12/21/08
to
r a écrit :
(snip clueless rant)
> One more big complaint "THE BACKSLASH PLAGUE". ever tried regexp?

Yes.

exp = re.compile(r"no \problem \with \backslashes")

>, or
> file paths?.

You mean _dos/windows_ file path separator ? It was indeed a stupid
choice _from microsoft_ to choose the by then well established escape
char (the backslash) as a file path separator. But hopefully, Python
handles it gracefully: you can either use raw strings (which I stronly
advise you learn about instead of whining) or just the traditional unix
one (forward slash) instead.

> All because that little backslash char is a line
> continuation character,

Totally clueless, as usual... Why don't you just READ THAT FUCKING MANUAL ?

Bruno Desthuilliers

unread,
Dec 21, 2008, 2:28:55 PM12/21/08
to
walterbyrd a écrit :

> On Dec 20, 5:05 pm, Roy Smith <r...@panix.com>
>
>> He got really hung up on the % syntax.
>
> I guess it's good to know that there is, at least, one person in the
> world doesn't like the % formatting. As least the move was not
> entirely pointless.
>
> But, you must admit, of all the things people complain about with
> Python, the % formatting is probably one of the least common
> complaints. Complaints about Python's speed seem much more common.

<dead-horse-beaten-to-hell-and-back>
People complaining about the perceived issues wrt/ Python's speed are
welcome to fix it. As far as I'm concerned, I find the perfs more than
acceptable when you take Python's dynamism into account. Strange enough,
no one seems to complain about PHP or Ruby's performances...
</dead-horse-beaten-to-hell-and-back>

> Yet, 3.0 makes the speed worse,

first make it right, then make it fast...

> and "fixes" a non-problem.
>
> I can see where the new formatting might be helpful in some cases.
> But, I am not sure it's worth the cost.

Err... _Which_ cost exactly ?

Bruno Desthuilliers

unread,
Dec 21, 2008, 2:41:37 PM12/21/08
to
r a écrit :

> I noticed when i mentioned "self" nobody wants to touch that subject.
> There could be many reasons why...
>
> 0.) nobody but the 10 regulars i see here exists
> 1.) nobody cares(doubt it)
> 2.) nobody is brave enough to question it(maybe)
> 3.) most people like to type self over and over again(doubt it)
> 4.) most people here have given up on changing the BDFL's mind about
> it. (good possibility)
> 5.) this is a hot-button topic(no doubt in my mind!)

6.) you are definitevely clueless.

(snip)

> I love python's classes, but HATE self.redundant!

This declaration only makes clear that answer to your above question is #6.

> This really needs to
> be fixed,

Your ignorance needs to be fixed, yes, indeed. Please go and fix it -
all the relevant materials is available in (or linked from somewhere in)
this newgroup's archives.

> and you have not heard the last from me about it!!!

As far as I'm concerned, yes. Welcome to my bozo filter. Please come
back when you'll have grown a brain.

It is loading more messages.
0 new messages