Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #18258 > unrolled thread

.format vs. %

Back to article view | Back to comp.lang.python

Contents

  .format vs. % davidfx <dgeorge29ca@gmail.com> - 2011-12-31 10:19 -0800
    Re: .format vs. % Andrew Berg <bahamutzero8825@gmail.com> - 2011-12-31 12:34 -0600
    Re: .format vs. % Yaşar Arabacı <yasar11732@gmail.com> - 2011-12-31 20:34 +0200
      Re: .format vs. % davidfx <dgeorge29ca@gmail.com> - 2011-12-31 10:44 -0800
      Re: .format vs. % davidfx <dgeorge29ca@gmail.com> - 2011-12-31 10:44 -0800
        Re: .format vs. % Yaşar Arabacı <yasar11732@gmail.com> - 2011-12-31 20:51 +0200
        Re: .format vs. % Evan Driscoll <edriscoll@wisc.edu> - 2011-12-31 13:47 -0500
          Re: .format vs. % Miki Tebeka <miki.tebeka@gmail.com> - 2012-01-01 13:11 -0800
            Re: .format vs. % Terry Reedy <tjreedy@udel.edu> - 2012-01-02 05:29 -0500
          Re: .format vs. % Miki Tebeka <miki.tebeka@gmail.com> - 2012-01-01 13:11 -0800
        Re: .format vs. % Alexander Kapps <alex.kapps@web.de> - 2011-12-31 19:59 +0100
        Re: .format vs. % Tim Chase <python.list@tim.thechases.com> - 2011-12-31 13:24 -0600
        Re: .format vs. % Lie Ryan <lie.1296@gmail.com> - 2012-01-01 06:34 +1100
        Re: .format vs. % Robert Kern <robert.kern@gmail.com> - 2011-12-31 19:43 +0000
        Re: .format vs. % Terry Reedy <tjreedy@udel.edu> - 2011-12-31 16:09 -0500
    Re: .format vs. % Ethan Furman <ethan@stoneleaf.us> - 2012-01-02 14:00 -0800
      Re: .format vs. % Rick Johnson <rantingrickjohnson@gmail.com> - 2012-01-02 17:59 -0800
        Re: .format vs. % Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2012-01-03 03:52 +0000
          Re: .format vs. % Ian Kelly <ian.g.kelly@gmail.com> - 2012-01-02 22:58 -0700
            Re: .format vs. % Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2012-01-03 06:15 +0000
              Re: .format vs. % Ian Kelly <ian.g.kelly@gmail.com> - 2012-01-03 01:16 -0700
              Re: .format vs. % Ethan Furman <ethan@stoneleaf.us> - 2012-01-03 05:26 -0800
              Re: .format vs. % Ethan Furman <ethan@stoneleaf.us> - 2012-01-03 11:38 -0800
              Re: .format vs. % Devin Jeanpierre <jeanpierreda@gmail.com> - 2012-01-03 15:02 -0500
              Re: .format vs. % Ethan Furman <ethan@stoneleaf.us> - 2012-01-03 12:16 -0800
          Re: .format vs. % Andrew Berg <bahamutzero8825@gmail.com> - 2012-01-03 04:55 -0600
          Re: .format vs. % Stefan Krah <stefan-usenet@bytereef.org> - 2012-01-03 12:47 +0100
            Re: .format vs. % Neil Cerutti <neilc@norwich.edu> - 2012-01-03 13:58 +0000
              Re: .format vs. % Stefan Krah <stefan-usenet@bytereef.org> - 2012-01-03 15:17 +0100
                Re: .format vs. % Neil Cerutti <neilc@norwich.edu> - 2012-01-03 15:15 +0000
                  Re: .format vs. % Neil Cerutti <neilc@norwich.edu> - 2012-01-03 15:24 +0000
            Re: .format vs. % Neil Cerutti <neilc@norwich.edu> - 2012-01-03 19:46 +0000
              Re: .format vs. % Ethan Furman <ethan@stoneleaf.us> - 2012-01-03 12:00 -0800
              Re: .format vs. % Stefan Krah <stefan-usenet@bytereef.org> - 2012-01-03 21:53 +0100
          Re: .format vs. % Chris Angelico <rosuav@gmail.com> - 2012-01-04 00:04 +1100
    Re: .format vs. % Rick Johnson <rantingrickjohnson@gmail.com> - 2012-01-02 17:51 -0800
      Re: .format vs. % Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2012-01-03 03:47 +0000
    Re: .format vs. % 88888 Dihedral <dihedral88888@googlemail.com> - 2012-01-03 07:47 -0800
      Re: .format vs. % alex23 <wuwei23@gmail.com> - 2012-01-03 18:26 -0800
        Re: .format vs. % 88888 Dihedral <dihedral88888@googlemail.com> - 2012-01-04 00:25 -0800
          Re: .format vs. % alex23 <wuwei23@gmail.com> - 2012-01-04 16:23 -0800
            Re: .format vs. % 88888 Dihedral <dihedral88888@googlemail.com> - 2012-01-04 17:41 -0800

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

#18382

On Mon, Jan 2, 2012 at 11:15 PM, Steven D'Aprano
<steve+comp.lang.python@pearwood.info> wrote:
> 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

[toc] | [prev] | [next] | [standalone]

#18404

Ian Kelly wrote:
> 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.

Ian Kelly wrote:
> 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.

Ian Kelly wrote:
> 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~

[toc] | [prev] | [next] | [standalone]

#18443

Ian Kelly wrote:
>>> http://mail.python.org/pipermail/python-dev/2009-September/092399.html
> 
> 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~

[toc] | [prev] | [next] | [standalone]

#18445

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

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

For me, sprintf-formatting is "obviously" easier to use (less typing)
unless you're pulling values from a dictionary or object, or already
have all the variables stored in a dict you can pass in with **d.

-- Devin

On Tue, Jan 3, 2012 at 8:26 AM, Ethan Furman <ethan@stoneleaf.us> wrote:
> Ian Kelly wrote:
>>
>> 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.
>
>
> Ian Kelly wrote:
>>
>> 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.
>
>
> Ian Kelly wrote:
>>
>> 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~
> --
> http://mail.python.org/mailman/listinfo/python-list

[toc] | [prev] | [next] | [standalone]

#18449

Devin Jeanpierre wrote:
>> "one obvious way" != "only one way"
> 
> 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~

[toc] | [prev] | [next] | [standalone]

#18391

On 1/2/2012 11:58 PM, Ian Kelly wrote:
> 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.

-- 
CPython 3.2.2 | Windows NT 6.1.7601.17640

[toc] | [prev] | [next] | [standalone]

#18395

Andrew Berg <bahamutzero8825@gmail.com> wrote:
> 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

[toc] | [prev] | [next] | [standalone]

#18406

On 2012-01-03, Stefan Krah <stefan-usenet@bytereef.org> wrote:
> Andrew Berg <bahamutzero8825@gmail.com> wrote:
>> 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.
   
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))
       ...

-- 
Neil Cerutti

[toc] | [prev] | [next] | [standalone]

#18409

Neil Cerutti <neilc@norwich.edu> wrote:
> > 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))
>        ...

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


Stefan Krah

[toc] | [prev] | [next] | [standalone]

#18414

On 2012-01-03, Stefan Krah <stefan-usenet@bytereef.org> wrote:
> Neil Cerutti <neilc@norwich.edu> wrote:
>> > 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))
>>        ...
>
> Did you profile this? I did, and it still adds 22% to the runtime.

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

-- 
Neil Cerutti

[toc] | [prev] | [next] | [standalone]

#18418

On 2012-01-03, Neil Cerutti <neilc@norwich.edu> wrote:
> On 2012-01-03, Stefan Krah <stefan-usenet@bytereef.org> wrote:
>> Neil Cerutti <neilc@norwich.edu> wrote:
>>> > 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))
>>>        ...
>>
>> Did you profile this? I did, and it still adds 22% to the runtime.
>
> No, I did not. And that's disappointing.

On many levels. Thanks for the correction.

-- 
Neil Cerutti

[toc] | [prev] | [next] | [standalone]

#18441

On 2012-01-03, Stefan Krah <stefan-usenet@bytereef.org> wrote:
> Andrew Berg <bahamutzero8825@gmail.com> wrote:
>> 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

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

-- 
Neil Cerutti

[toc] | [prev] | [next] | [standalone]

#18452

Neil Cerutti wrote:
> On 2012-01-03, Stefan Krah <stefan-usenet@bytereef.org> wrote:
>> Andrew Berg <bahamutzero8825@gmail.com> wrote:
>>> 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
> 
> 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~

[toc] | [prev] | [next] | [standalone]

#18453

Neil Cerutti <neilc@norwich.edu> wrote:
> On 2012-01-03, Stefan Krah <stefan-usenet@bytereef.org> wrote:
> > $ ./python -m timeit -n 1000000 '"%s" % 7.928137192'
> > 1000000 loops, best of 3: 0.0164 usec per loop
> 
> % 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:

>>> "{:020,}".format(712312312.2)
'00,000,712,312,312.2'


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


Stefan Krah

[toc] | [prev] | [next] | [standalone]

#18401

On Tue, Jan 3, 2012 at 10:47 PM, Stefan Krah <stefan-usenet@bytereef.org> wrote:
> 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

[toc] | [prev] | [next] | [standalone]

#18363

On Dec 31 2011, 12:19 pm, davidfx <dgeorge2...@gmail.com> wrote:
> Hello everyone,
> I just have a quick question about .format and %r %s %d.
>
> Should we always be using .format() for formatting strings or %?

ALWAYS use the format method over the old and dumpy string
interpolation. Why? Well because the format method is so much more
powerful, elegant, and the way of the future. Some might argue that
format is slower than interpolation (and i can't comment in favor of
either) HOWEVER, if speed is your concern than interpolation is NOT
the answer.

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

That question has been answered many times in this thread already.

You may find the format spec to be cryptic at first. Well, most find
regexes cryptic also -- but would anyone recommend NOT using regexes
just because of crypti-ness? I think not. It's a non-starter.

[toc] | [prev] | [next] | [standalone]

#18368

On Mon, 02 Jan 2012 17:51:48 -0800, Rick Johnson wrote:

> You may find the format spec to be cryptic at first. Well, most find
> regexes cryptic also -- but would anyone recommend NOT using regexes
> just because of crypti-ness? I think not. It's a non-starter.

I would.

If you have a task that doesn't *need* a regular expression solution, 
don't use a regular expression.


For what it's worth, I like the syntax of % formatting. It's nice and 
simple and compact while still being readable. format() is more powerful, 
but when I don't need that power, I stick to % formatting.


-- 
Steven

[toc] | [prev] | [next] | [standalone]

#18420

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. 

[toc] | [prev] | [next] | [standalone]

#18482

88888 Dihedral <dihedral88...@googlemail.com> wrote:
> 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?

[toc] | [prev] | [next] | [standalone]

#18492

alex23於 2012年1月4日星期三UTC+8上午10時26分35秒寫道：
> 88888 Dihedral <dihedr...@googlemail.com> wrote:
> > 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?
> 

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. 


> > Boa and wxpython are still not good enough.
> 
> 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?

[toc] | [prev] | [next] | [standalone]

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

Back to top | Article view | comp.lang.python

csiph-web