.format vs. %

[Steven D'Aprano]

I can't believe I'm taking Rick's side here, but the docs do say:

"Note: The formatting operations described here are obsolete and may go
away in future versions of Python. Use the new String Formatting in new
code."

http://docs.python.org/py3k/library/stdtypes.html#old-string-formatting- operations

I consider that a statement of deprecation, even if it doesn't use the
term explicitly or describe a definite timeline for removal.

Which is exactly why it is not deprecated: it doesn't say it is
deprecated and has no timeline for removal. It may not even be removed:
"may" go away is not "will" go away.

Going around saying that features are deprecated just because they may
(or may not) some day in the distant future become deprecated is FUD. It
simply isn't true that % formatting is deprecated: Python Dev has a
formal process for deprecating code, and that process has not been
applied to % and there are no plans to do so in the foreseeable future.

There is a huge code base using this feature, including the standard
library, and Python does not arbitrarily deprecate features used by real
code without good reason. Just because a number of Python devs want to
encourage people to use format doesn't imply that % will go away any time
before Python 4000.

 

[Ian Kelly]

Which is exactly why it is not deprecated: it doesn't say it is
deprecated and has no timeline for removal. It may not even be removed:
"may" go away is not "will" go away.

Going around saying that features are deprecated just because they may
(or may not) some day in the distant future become deprecated is FUD. It
simply isn't true that % formatting is deprecated: Python Dev has a
formal process for deprecating code, and that process has not been
applied to % and there are no plans to do so in the foreseeable future.

So it's not formally deprecated, but it is nonetheless labeled
obsolete and discouraged, or "informally deprecated" if you will.

I'm not sure it's true that "there are no plans to do so in the
foreseeable future." According to the release notes from Python 3.0,
% formatting was supposed to be deprecated in Python 3.1. Why that
didn't happen, I don't know. Maybe there was a discussion on py-dev
where it was decided that % formatting would not be deprecated after
all (in which case the misleading "obsolete" note really ought to be
removed from the documentation). Maybe that discussion has been
tabled for the time being. Or maybe it hasn't been deprecated simply
because nobody has gotten around to actually doing it yet.

In any case the statement of obsolescence and the lack of clarity
about the feature's future is enough cause for me to avoid the
feature, although you of course are free to use it however you want.

There is a huge code base using this feature, including the standard
library, and Python does not arbitrarily deprecate features used by real
code without good reason. Just because a number of Python devs want to
encourage people to use format doesn't imply that % will go away any time
before Python 4000.

The reason for deprecating it is because Python currently has no fewer
than three mechanisms for string formatting (not even including
ordinary string concatenation), which according to the Zen of Python
is two too many. In my view, % formatting has a lot in common with
the print statement -- it's warty syntax that is better implemented as
a function. In Python 3 we could have kept the print statement and
avoided breaking a feature commonly used by "real code" by adding the
print function as a supplement to the statement (probably with a
slightly different name). But the devs went a step further and
actually removed the print statement, and IMO that was a good thing.
The same thing should be done with % formatting (although I agree on
one point, it likely won't happen before Python 4).

Cheers,
Ian

 

[Andrew Berg]

I can't believe I'm taking Rick's side here, but the docs do say:

"Note: The formatting operations described here are obsolete and may
go away in future versions of Python. Use the new String Formatting in
new code."

http://docs.python.org/py3k/library/stdtypes.html#old-string-formatting-operations

And that is mainly what I based my statement on. As I said, it's not
likely to be any time soon. I highly doubt it will even become
deprecated in 3.3, but it wouldn't surprise me if it becomes deprecated
in 3.4 and removed in 4.0. In any case, I should've said "will probably
go away".

To add my opinion on it, I find format() much more readable and easier
to understand (with the exception of the {} {} {} {} syntax), and would
love to see %-style formatting phased out.

 

[Stefan Krah]

To add my opinion on it, I find format() much more readable and easier
to understand (with the exception of the {} {} {} {} syntax), and would
love to see %-style formatting phased out.

For me the %-style is much more readable. Also, it is significantly
faster:

$ ./python -m timeit -n 1000000 '"%s" % 7.928137192'
1000000 loops, best of 3: 0.0164 usec per loop
$ ./python -m timeit -n 1000000 '"{}".format(7.928137192)'
1000000 loops, best of 3: 1.01 usec per loop


In the real-world telco benchmark for _decimal, replacing the single line

outfil.write("%s\n" % t)

with

outfil.write("{}\n".format(t))


adds 23% to the runtime. I think %-style formatting should not be
deprecated at all.


Stefan Krah

 

[Chris Angelico]

For me the %-style is much more readable.

It's also very similar to C's printf, which means it's similar to
everything else that's similar to printf. That makes it instantly
grokkable to many many people, which is a Good Thing. It's like using
the + operator for string concatenation - there's no requirement to do
so, and not all languages do (REXX, PHP, and SQL come to mind); but
supporting the "obvious thing" gives a huge slab of potential Python
users the chance to understand and write code with one less trip to
the documentation.

ChrisA

 

[Ethan Furman]

I'm not sure it's true that "there are no plans to do so in the
foreseeable future." According to the release notes from Python 3.0,
% formatting was supposed to be deprecated in Python 3.1.

Eric Smith wrote (from a thread on pydev in 02-2011):

The last thread on this I have a reference to was in September 2009. I
think was basically the outcome:
http://mail.python.org/pipermail/python-dev/2009-September/092399.html

So there will be no deprecation, just a gradual shift to PEP 3101
formatting.

Maybe there was a discussion on py-dev
where it was decided that % formatting would not be deprecated after
all (in which case the misleading "obsolete" note really ought to be
removed from the documentation).

Agreed that this is a documentation bug.

The reason for deprecating it is because Python currently has no fewer
than three mechanisms for string formatting (not even including
ordinary string concatenation), which according to the Zen of Python
is two too many.

"one obvious way" != "only one way"

~Ethan~

 

[Neil Cerutti]

For me the %-style is much more readable. Also, it is significantly
faster:

$ ./python -m timeit -n 1000000 '"%s" % 7.928137192'
1000000 loops, best of 3: 0.0164 usec per loop
$ ./python -m timeit -n 1000000 '"{}".format(7.928137192)'
1000000 loops, best of 3: 1.01 usec per loop

In the real-world telco benchmark for _decimal, replacing the
single line

outfil.write("%s\n" % t)

with

outfil.write("{}\n".format(t))

adds 23% to the runtime. I think %-style formatting should not
be deprecated at all.

When it becomes necessary, it's possible to optimize it by
hoisting out the name lookups.
...
outfil_write = outfil.write
append_newline = "{}\n".format
...
outfil_write(append_newline(t))
...

 

[Stefan Krah]

When it becomes necessary, it's possible to optimize it by
hoisting out the name lookups.
...
outfil_write = outfil.write
append_newline = "{}\n".format
...
outfil_write(append_newline(t))
...

Did you profile this? I did, and it still adds 22% to the runtime.


Stefan Krah

 

[Neil Cerutti]

Did you profile this? I did, and it still adds 22% to the runtime.

No, I did not. And that's disappointing.

 

[Neil Cerutti]

No, I did not. And that's disappointing.

On many levels. Thanks for the correction.

 

[88888 Dihedral]

davidfxæ–¼ 2012å¹´1月1日星期日UTC+8上åˆ2時19分34秒寫é“：

Hello everyone,
I just have a quick question about .format and %r %s %d.

Should we always be using .format() for formatting strings or %?

Example a = 'apples'
print "I love {0}.".format(a)

If I wanted to put .format into a variable, how would I do that.

Thanks for your information in advance.

David

This is a good evolution in Python. It is 2012 now and the text I/O part
is not as important as 10 years ago. The next move of Python could
be easy integration of C++ libraries.

The auto code generation part for low-paid tedious GUI tasks is still missing
in the standard Python.

Boa and wxpython are still not good enough.

 

[Ethan Furman]

Thanks, that link is very informative.

Here's the link to the last discussion last February:

http://mail.python.org/pipermail/python-dev/2011-February/108155.html

~Ethan~

 

[Neil Cerutti]

For me the %-style is much more readable. Also, it is significantly
faster:

$ ./python -m timeit -n 1000000 '"%s" % 7.928137192'
1000000 loops, best of 3: 0.0164 usec per loop

I have done a little more investigating, and the above is
arguably not fair. Python is interpolating that string at compile
time, as far as I can tell. Pretty cool, and not possible with
..format, but it's just regurgitating a string literal over and
over, which isn't of much interest.

% is faster, but not by an order of magnitude.

On my machine:

C:\WINDOWS>python -m timeit -n 1000000 -s "n=7.92" "'%s' % n"
1000000 loops, best of 3: 0.965 usec per loop

C:\WINDOWS>python -m timeit -n 1000000 -s "n=7.92" "'{}'.format(n)"
1000000 loops, best of 3: 1.17 usec per loop

 

[Ethan Furman]

I have done a little more investigating, and the above is
arguably not fair. Python is interpolating that string at compile
time, as far as I can tell. Pretty cool, and not possible with
.format, but it's just regurgitating a string literal over and
over, which isn't of much interest.

% is faster, but not by an order of magnitude.

On my machine:

C:\WINDOWS>python -m timeit -n 1000000 -s "n=7.92" "'%s' % n"
1000000 loops, best of 3: 0.965 usec per loop

C:\WINDOWS>python -m timeit -n 1000000 -s "n=7.92" "'{}'.format(n)"
1000000 loops, best of 3: 1.17 usec per loop

Good information. Thanks.

~Ethan~

 

[Ethan Furman]

Which way is the obvious way? Why is it obvious?

Apparently, %-style is obvious to C and similar coders, while {}-style
is obvious to Java and similar coders.



~Ethan~

 

[Stefan Krah]

% is faster, but not by an order of magnitude.

On my machine:

C:\WINDOWS>python -m timeit -n 1000000 -s "n=7.92" "'%s' % n"
1000000 loops, best of 3: 0.965 usec per loop

C:\WINDOWS>python -m timeit -n 1000000 -s "n=7.92" "'{}'.format(n)"
1000000 loops, best of 3: 1.17 usec per loop

Indeed, I was a bit surprised by the magnitude of the difference.

Your timings seem to be in line with the difference seen in the
real-world benchmark. It isn't a big deal, considering that the
numeric formatting functions have to so many options, e.g:
'00,000,712,312,312.2'


Still, it's nice to have a faster choice.


Stefan Krah

 

[alex23]

This is a good evolution in Python. It is 2012 now and the text I/O part
is not as important as 10 years ago. The next move of Python could
be easy integration of C++ libraries.

You mean like with Py++? http://pypi.python.org/pypi/pyplusplus/

The auto code generation part for low-paid tedious   GUI tasks  is still missing
in the standard Python.

Wait, what? How is it the Python community's responsibility to relieve
talentless code-monkeys of their tedium? Why can't they write their
own damn code generators?

Boa and wxpython are still not good enough.

And what are you contributing to the situation other than
misinformation and markov-generated spam?

 

[88888 Dihedral]

alex23æ–¼ 2012å¹´1月4日星期三UTC+8上åˆ10時26分35秒寫é“：

You mean like with Py++? http://pypi.python.org/pypi/pyplusplus/


Wait, what? How is it the Python community's responsibility to relieve
talentless code-monkeys of their tedium? Why can't they write their
own damn code generators?

I think a code generator to assist the programmer for
common tedious boring GUI jobs such as BOA is more important in Python.

But Python is not VB.

And what are you contributing to the situation other than
misinformation and markov-generated spam?

Do you know what can attract newbies to support python?

 

[alex23]

Do you know what can attract newbies to support python?

I'm sure other people doing all the work for them would be a great
attractor. Are you volunteering to work on this code generator?

 

[88888 Dihedral]

alex23æ–¼ 2012å¹´1月5日星期四UTC+8上åˆ8時23分06秒寫é“：

I'm sure other people doing all the work for them would be a great
attractor. Are you volunteering to work on this code generator?

I am working on the code generation problem in other applications.

I could contribute some opinions about this problem.

I think the BOA project is in the right direction.