Re: .format vs. %
alex23於 2012年1月5日星期四UTC+8上午8時23分06秒寫道： > On Jan 4, 6:25 pm, 8 Dihedral > wrote: > > > 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? > > 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. -- http://mail.python.org/mailman/listinfo/python-list
Re: .format vs. %
On Jan 4, 6:25 pm, 8 Dihedral wrote: > > 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? 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? -- http://mail.python.org/mailman/listinfo/python-list
Re: .format vs. %
alex23於 2012年1月4日星期三UTC+8上午10時26分35秒寫道： > 8 Dihedral 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? -- http://mail.python.org/mailman/listinfo/python-list
Re: .format vs. %
8 Dihedral 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? -- http://mail.python.org/mailman/listinfo/python-list
Re: .format vs. %
Neil Cerutti wrote:
> On 2012-01-03, Stefan Krah wrote:
> > $ ./python -m timeit -n 100 '"%s" % 7.928137192'
> > 100 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 100 -s "n=7.92" "'%s' % n"
> 100 loops, best of 3: 0.965 usec per loop
>
> C:\WINDOWS>python -m timeit -n 100 -s "n=7.92" "'{}'.format(n)"
> 100 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
--
http://mail.python.org/mailman/listinfo/python-list
Re: .format vs. %
Neil Cerutti wrote:
On 2012-01-03, Stefan Krah wrote:
Andrew Berg 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 100 '"%s" % 7.928137192'
100 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 100 -s "n=7.92" "'%s' % n"
100 loops, best of 3: 0.965 usec per loop
C:\WINDOWS>python -m timeit -n 100 -s "n=7.92" "'{}'.format(n)"
100 loops, best of 3: 1.17 usec per loop
Good information. Thanks.
~Ethan~
--
http://mail.python.org/mailman/listinfo/python-list
Re: .format vs. %
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~
--
http://mail.python.org/mailman/listinfo/python-list
Re: .format vs. %
On 3 January 2012 19:46, Neil Cerutti wrote:
> On 2012-01-03, Stefan Krah wrote:
> > Andrew Berg 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 100 '"%s" % 7.928137192'
> > 100 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 100 -s "n=7.92" "'%s' % n"
> 100 loops, best of 3: 0.965 usec per loop
>
> C:\WINDOWS>python -m timeit -n 100 -s "n=7.92" "'{}'.format(n)"
> 100 loops, best of 3: 1.17 usec per loop
Cool! And you can make up half the difference, too:
%~> python -m timeit -n 100 -s "n=7.92" "'%s' % n"
100 loops, best of 3: 1.27 usec per loop
%~> python -m timeit -n 100 -s "n=7.92" "'{}'.format(n)"
100 loops, best of 3: 1.81 usec per loop
%~> python -m timeit -n 100 -s "n=7.92; x='{}'.format" "x(n)"
100 loops, best of 3: 1.51 usec per loop
--
http://mail.python.org/mailman/listinfo/python-list
Re: .format vs. %
> "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 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 -- http://mail.python.org/mailman/listinfo/python-list
Re: .format vs. %
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~ -- http://mail.python.org/mailman/listinfo/python-list
Re: .format vs. %
On 2012-01-03, Stefan Krah wrote:
> Andrew Berg 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 100 '"%s" % 7.928137192'
> 100 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 100 -s "n=7.92" "'%s' % n"
100 loops, best of 3: 0.965 usec per loop
C:\WINDOWS>python -m timeit -n 100 -s "n=7.92" "'{}'.format(n)"
100 loops, best of 3: 1.17 usec per loop
--
Neil Cerutti
--
http://mail.python.org/mailman/listinfo/python-list
Re: .format vs. %
On Jan 3, 2012 6:55 AM, "Ethan Furman" 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. Thanks, that link is very informative. -- http://mail.python.org/mailman/listinfo/python-list
Re: .format vs. %
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.
--
http://mail.python.org/mailman/listinfo/python-list
Re: .format vs. %
On 2012-01-03, Neil Cerutti wrote:
> On 2012-01-03, Stefan Krah wrote:
>> Neil Cerutti 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
--
http://mail.python.org/mailman/listinfo/python-list
Re: .format vs. %
On 2012-01-03, Stefan Krah wrote:
> Neil Cerutti 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
--
http://mail.python.org/mailman/listinfo/python-list
Re: .format vs. %
Neil Cerutti 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
--
http://mail.python.org/mailman/listinfo/python-list
Re: .format vs. %
On 2012-01-03, Stefan Krah wrote:
> Andrew Berg 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 100 '"%s" % 7.928137192'
> 100 loops, best of 3: 0.0164 usec per loop
> $ ./python -m timeit -n 100 '"{}".format(7.928137192)'
> 100 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
--
http://mail.python.org/mailman/listinfo/python-list
Re: .format vs. %
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
Re: .format vs. %
On Tue, Jan 3, 2012 at 10:47 PM, Stefan Krah 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 -- http://mail.python.org/mailman/listinfo/python-list
Re: .format vs. %
Andrew Berg 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 100 '"%s" % 7.928137192'
100 loops, best of 3: 0.0164 usec per loop
$ ./python -m timeit -n 100 '"{}".format(7.928137192)'
100 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
--
http://mail.python.org/mailman/listinfo/python-list
Re: .format vs. %
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
--
http://mail.python.org/mailman/listinfo/python-list
Re: .format vs. %
On Mon, Jan 2, 2012 at 11:15 PM, Steven D'Aprano 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 -- http://mail.python.org/mailman/listinfo/python-list
Re: .format vs. %
On Mon, 02 Jan 2012 22:58:23 -0700, Ian Kelly wrote: > On Mon, Jan 2, 2012 at 8:52 PM, Steven D'Aprano > wrote: >> On Mon, 02 Jan 2012 17:59:43 -0800, Rick Johnson wrote: >> >>> On Jan 2, 4:00 pm, Ethan Furman wrote: %-style formatting isn't going away. >>> >>> You may want to freshen up on the definition of "deprecation". >> >> I'm sure Ethan knows the definition of deprecation. I'm sure he also >> knows that % formatting is NOT deprecated. Please stop spreading FUD >> about Python features. > > 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. -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: .format vs. %
On Mon, Jan 2, 2012 at 8:52 PM, Steven D'Aprano wrote: > On Mon, 02 Jan 2012 17:59:43 -0800, Rick Johnson wrote: > >> On Jan 2, 4:00 pm, Ethan Furman wrote: >>> %-style formatting isn't going away. >> >> You may want to freshen up on the definition of "deprecation". > > I'm sure Ethan knows the definition of deprecation. I'm sure he also > knows that % formatting is NOT deprecated. Please stop spreading FUD > about Python features. 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. Cheers, Ian -- http://mail.python.org/mailman/listinfo/python-list
Re: .format vs. %
On Mon, 02 Jan 2012 17:59:43 -0800, Rick Johnson wrote: > On Jan 2, 4:00 pm, Ethan Furman wrote: >> %-style formatting isn't going away. > > You may want to freshen up on the definition of "deprecation". I'm sure Ethan knows the definition of deprecation. I'm sure he also knows that % formatting is NOT deprecated. Please stop spreading FUD about Python features. -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: .format vs. %
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 -- http://mail.python.org/mailman/listinfo/python-list
Re: .format vs. %
On Dec 31 2011, 12:19 pm, davidfx 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. -- http://mail.python.org/mailman/listinfo/python-list
Re: .format vs. %
On Jan 2, 4:00 pm, Ethan Furman wrote: > %-style formatting isn't going away. You may want to freshen up on the definition of "deprecation". If it was NOT going away, why the need to deprecate it? hmm? It would be more beneficial if you DO NOT encourage continued usage of this "end- of-life" feature. http://en.wikipedia.org/wiki/Deprecation -- http://mail.python.org/mailman/listinfo/python-list
Re: .format vs. %
Andrew Berg wrote: On 12/31/2011 12:19 PM, davidfx wrote: Should we always be using .format() for formatting strings or %? >> %-style formatting will eventually go away, but probably not for a long time. %-style formatting isn't going away. ~Ethan~ -- http://mail.python.org/mailman/listinfo/python-list
Re: .format vs. %
On 1/1/2012 4:11 PM, Miki Tebeka wrote:
s = "{0} {1} {2} {3}"
s.format(1, 2, 3, 4)
'1 2 3 4'
Or even
In [4]: fmt = '{0} {1} {2} {3}'.format
In [5]: print(fmt(1, 2, 3, 4))
1 2 3 4
I have done this, except for using a more informative name, like 'emsg'
for error message.
except XError as e:
print(emsg(a,b,c,e))
makes for pretty clear code.
--
Terry Jan Reedy
--
http://mail.python.org/mailman/listinfo/python-list
Re: .format vs. %
> >>> s = "{0} {1} {2} {3}"
> >>> s.format(1, 2, 3, 4)
> '1 2 3 4'
Or even
In [4]: fmt = '{0} {1} {2} {3}'.format
In [5]: print(fmt(1, 2, 3, 4))
1 2 3 4
--
http://mail.python.org/mailman/listinfo/python-list
Re: .format vs. %
On 12/31/2011 2:24 PM, Tim Chase wrote:
On 12/31/11 12:57, Benjamin Kaplan wrote:
format is a method of the string class. You store the string the same way
you would any other.
formatter = "Hello, {}"
print(formatter.format("world"))
Just to note that this syntax doesn't quite work in some earlier
versions (tested below in 2.6, which came stock in Debian Stable)
Autonumbering of {} was introduced, at my suggestion, in 3.1 and
included with 2.7 (I presume).
>>> formatter = "Hello, {}"
>>> print(formatter.format("world"))
Traceback (most recent call last):
File "", line 1, in
ValueError: zero length field name in format
It needs to be spelled "{0}"
-tkc
--
Terry Jan Reedy
--
http://mail.python.org/mailman/listinfo/python-list
Re: .format vs. %
On 12/31/11 7:34 PM, Lie Ryan wrote:
On 01/01/2012 05:44 AM, davidfx wrote:
Thanks for your response. I know the following code is not going to be correct
but I want to show you what I was thinking.
formatter = "%r %r %r %r"
print formatter % (1, 2, 3, 4)
What is the .format version of this concept?
I don't think the (%r)epr-formatting exist anymore, so if you want to do that
you'll need to call repr manually.
Yes, it does.
formatter = '{!r} {!r} {!r} {!r}'
print formatter.format(1,2,3,4)
--
Robert Kern
"I have come to believe that the whole world is an enigma, a harmless enigma
that is made terrible by our own mad attempt to interpret it as though it had
an underlying truth."
-- Umberto Eco
--
http://mail.python.org/mailman/listinfo/python-list
Re: .format vs. %
On 01/01/2012 05:44 AM, davidfx wrote: Thanks for your response. I know the following code is not going to be correct but I want to show you what I was thinking. formatter = "%r %r %r %r" print formatter % (1, 2, 3, 4) What is the .format version of this concept? I don't think the (%r)epr-formatting exist anymore, so if you want to do that you'll need to call repr manually. -- http://mail.python.org/mailman/listinfo/python-list
Re: .format vs. %
On 12/31/11 12:57, Benjamin Kaplan wrote:
format is a method of the string class. You store the string the same way
you would any other.
formatter = "Hello, {}"
print(formatter.format("world"))
Just to note that this syntax doesn't quite work in some earlier
versions (tested below in 2.6, which came stock in Debian Stable)
>>> formatter = "Hello, {}"
>>> print(formatter.format("world"))
Traceback (most recent call last):
File "", line 1, in
ValueError: zero length field name in format
It needs to be spelled "{0}"
-tkc
--
http://mail.python.org/mailman/listinfo/python-list
Re: .format vs. %
On 31.12.2011 19:44, davidfx wrote:
Thanks for your response. I know the following code is not going to be correct
but I want to show you what I was thinking.
formatter = "%r %r %r %r"
print formatter % (1, 2, 3, 4)
What is the .format version of this concept?
formatter = "{0} {1} {2} {3}"
formatter.format(1,2,3,4)
I have to say, I simply hate .format(), and I will be very, very
upset if classic formatting will really be removed.
I understand that .format() has a lot of advantages for more complex
formatting, but for the simple stuff I usually do, it's just
terribly inconvenient (try {} on a German keyboard).
--
http://mail.python.org/mailman/listinfo/python-list
Re: .format vs. %
On Dec 31, 2011 1:46 PM, "davidfx" wrote:
>
> Thanks for your response. I know the following code is not going to be
correct but I want to show you what I was thinking.
>
> formatter = "%r %r %r %r"
>
> print formatter % (1, 2, 3, 4)
>
> What is the .format version of this concept?
>
format is a method of the string class. You store the string the same way
you would any other.
formatter = "Hello, {}"
print(formatter.format("world"))
--
http://mail.python.org/mailman/listinfo/python-list
Re: .format vs. %
How 'bout just:
>>> s = "{0} {1} {2} {3}"
>>> s.format(1, 2, 3, 4)
'1 2 3 4'
Evan
On 12/31/2011 13:44, davidfx wrote:
> Thanks for your response. I know the following code is not going to be
> correct but I want to show you what I was thinking.
>
> formatter = "%r %r %r %r"
>
> print formatter % (1, 2, 3, 4)
>
> What is the .format version of this concept?
>
signature.asc
Description: OpenPGP digital signature
--
http://mail.python.org/mailman/listinfo/python-list
Re: .format vs. %
You mean like this?
===
a = "I like {name}"
a.format(name="myself")
'I like myself'
Sat, 31 Dec 2011 20:44:08 +0200 tarihinde davidfx
şöyle yazmış:
Thanks for your response. I know the following code is not going to be
correct but I want to show you what I was thinking.
formatter = "%r %r %r %r"
print formatter % (1, 2, 3, 4)
What is the .format version of this concept?
--
Opera'nın e-posta istemcisi ile gönderildi: http://www.opera.com/mail
--
http://mail.python.org/mailman/listinfo/python-list
Re: .format vs. %
Thanks for your response. I know the following code is not going to be correct but I want to show you what I was thinking. formatter = "%r %r %r %r" print formatter % (1, 2, 3, 4) What is the .format version of this concept? -- http://mail.python.org/mailman/listinfo/python-list
Re: .format vs. %
What exactly do you mean by putting .format into a variable? You mean like
this:
"{name} is very {adj}
{gender}".format(name="sandy",adj="diligent",gender="female")
Sat, 31 Dec 2011 20:19:34 +0200 tarihinde davidfx
şöyle yazmış:
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
--
Opera'nın e-posta istemcisi ile gönderildi: http://www.opera.com/mail
--
http://mail.python.org/mailman/listinfo/python-list
Re: .format vs. %
On 12/31/2011 12:19 PM, davidfx wrote: > Should we always be using .format() for formatting strings or %? In new code, yes. %-style formatting will eventually go away, but probably not for a long time. > If I wanted to put .format into a variable, how would I do that. What do you mean? -- CPython 3.2.2 | Windows NT 6.1.7601.17640 -- http://mail.python.org/mailman/listinfo/python-list
