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

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.

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!

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.

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.

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:

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.

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.

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.

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.

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.

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

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

from __future__ import braces

and see what happens.