Old to New String Formatting

_Bostjan_Mejak · May 24, 2013, 2:25pm

I suggest we fix all of Phoenix’s source to have the new string formatting.

Old string formatting example:

amount1 = “one”

amount2 = “two”

“I have %s apple and %s oranges.” % (amount1, amount2)

New string formatting example:

amount1 = “one”

amount2 = “two”

“I have {x} apple and {y} oranges.”.format(x=amount1, y=amount2)

I think the 2to3 tool would help.

Yoriz · May 24, 2013, 4:05pm

I suggest you let them fix the more important stuff and leave the if it isn’t broke don’t fix it stuff for the future.

···

On Friday, May 24, 2013 3:25:24 PM UTC+1, Boštjan Mejak wrote:

I suggest we fix all of Phoenix’s source to have the new string formatting.

Old string formatting example:

amount1 = “one”

amount2 = “two”

“I have %s apple and %s oranges.” % (amount1, amount2)

New string formatting example:

amount1 = “one”

amount2 = “two”

“I have {x} apple and {y} oranges.”.format(x=amount1, y=amount2)

I think the 2to3 tool would help.

Tim_Roberts · May 24, 2013, 4:42pm

There was a discussion just this week on comp.lang.python confirming
that %-style formatting will never go away.ï¿½ Thus, the
cost-to-benefit ratio of this suggestion is asymptotically high.
The only real gain in the {}-style formatting is environments when
you need to do internationalization.ï¿½ I don’t think that applies to
any of the string formatting within wxPython.

···

Boï¿½tjan Mejak wrote:

    I suggest we fix all of Phoenix's source to have

the new string formatting.

-- Tim Roberts, Providenza & Boekelheide, Inc.

timr@probo.com

Paul6 · May 28, 2013, 12:07pm

Boštjan Mejak wrote:

    I suggest we fix all of Phoenix's source to have

the new string formatting.

There was a discussion just this week on comp.lang.python confirming
that %-style formatting will never go away. Thus, the
cost-to-benefit ratio of this suggestion is asymptotically high.
The only real gain in the {}-style formatting is environments when
you need to do internationalization. I don’t think that applies to
any of the string formatting within wxPython.

Out of interest, what’s the benefit of new style formatting for internationalisation?

···

On 24 May 2013 17:42, Tim Roberts timr@probo.com wrote:

-- Tim Roberts, timr@probo.com
Providenza & Boekelheide, Inc.

–

You received this message because you are subscribed to the Google Groups “wxPython-users” group.

To unsubscribe from this group and stop receiving emails from it, send an email to wxpython-users+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/groups/opt_out.

Robin · May 29, 2013, 6:32am

Paul Wiseman wrote:

···

On 24 May 2013 17:42, Tim Roberts <timr@probo.com > <mailto:timr@probo.com>> wrote:

    Boštjan Mejak wrote:

    I suggest we fix all of Phoenix's source to have the new string
    formatting.

    There was a discussion just this week on comp.lang.python confirming
    that %-style formatting will never go away. Thus, the
    cost-to-benefit ratio of this suggestion is asymptotically high.

    The only real gain in the {}-style formatting is environments when
    you need to do internationalization. I don't think that applies to
    any of the string formatting within wxPython.

Out of interest, what's the benefit of new style formatting for
internationalisation?

One is that you can change the order that values are substituted into the string template, so different languages don't have to conform to the english order of value substitutions, so the text can seem more natural to the reader.

--
Robin Dunn
Software Craftsman

Werner · May 29, 2013, 7:17am

Hi,

Paul Wiseman wrote:

    Boštjan Mejak wrote:

    I suggest we fix all of Phoenix's source to have the new string
    formatting.

    There was a discussion just this week on comp.lang.python confirming
    that %-style formatting will never go away. Thus, the
    cost-to-benefit ratio of this suggestion is asymptotically high.

    The only real gain in the {}-style formatting is environments when
    you need to do internationalization. I don't think that applies to
    any of the string formatting within wxPython.

Out of interest, what's the benefit of new style formatting for
internationalisation?

One is that you can change the order that values are substituted into the string template, so different languages don't have to conform to the english order of value substitutions, so the text can seem more natural to the reader.

But that is possible with the old one too by doing something along these lines:

_(u"%(cellar)s - Vintages (%(minVint)i - %(maxVint)i): %(cVint)i, Drinks: %(cDrinks)i, Bottles: %(sQTY)i, Purchase value: %(sValP).2f, Current value: %(sValC).2f") % {
                                 'cellar': cellar,
                                 'cDrinks': cDrinks,
                                 'minVint': minVint,
                                 'maxVint': maxVint,
                                 'cVint': cVint,
                                 'sQTY': sQTY,
                                 'sValC': sValC,
                                 'sValP': sValP})

Werner

···

On 29/05/2013 08:32, Robin Dunn wrote:

On 24 May 2013 17:42, Tim Roberts <timr@probo.com >> <mailto:timr@probo.com>> wrote:

Robin · May 29, 2013, 4:45pm

werner wrote:

Hi,

Paul Wiseman wrote:

Boštjan Mejak wrote:

I suggest we fix all of Phoenix's source to have the new string
formatting.

There was a discussion just this week on comp.lang.python confirming
that %-style formatting will never go away. Thus, the
cost-to-benefit ratio of this suggestion is asymptotically high.

The only real gain in the {}-style formatting is environments when
you need to do internationalization. I don't think that applies to
any of the string formatting within wxPython.

Out of interest, what's the benefit of new style formatting for
internationalisation?

One is that you can change the order that values are substituted into
the string template, so different languages don't have to conform to
the english order of value substitutions, so the text can seem more
natural to the reader.

But that is possible with the old one too by doing something along these
lines:

_(u"%(cellar)s - Vintages (%(minVint)i - %(maxVint)i): %(cVint)i,
Drinks: %(cDrinks)i, Bottles: %(sQTY)i, Purchase value: %(sValP).2f,
Current value: %(sValC).2f") % {
'cellar': cellar,
'cDrinks': cDrinks,
'minVint': minVint,
'maxVint': maxVint,
'cVint': cVint,
'sQTY': sQTY,
'sValC': sValC,
'sValP': sValP})

Yes, that's true. IMO however the new syntax is a lot easier to read and to write (I can't count how many times I've forgotten the format character after the closing parenthesis.) Plus, you can change the substitution order of positional format values as well. For example, this:

_("You will find the {0} in the {1}").format(thing, place)

would work just as well if the string was translated to something like this in some other locale:

_("Look in the {1} to find the {0}").format(thing, place)

The new formatting syntax can also do cool Pythonic things like access an attribute of an object, or an indexed item from a sequence.

That said, I still find myself using the old-style format specification most of the time. Old habits are hard to break.

···

On 29/05/2013 08:32, Robin Dunn wrote:

On 24 May 2013 17:42, Tim Roberts <timr@probo.com >>> <mailto:timr@probo.com>> wrote:

--
Robin Dunn
Software Craftsman

Metallicow · July 7, 2013, 5:11pm

TimeIt Test

import timeit
timeitThisNumberTimes = 1000000

def TimeIt_StringFormattingOldVsNew():
“”“Test Old string formatting vs New string formatting”“”
print(‘TimeIt_StringFormattingOldVsNew’)
def Test1():
# Old string formatting example:
amount1 = “one”
amount2 = “two”
“I have %s apple and %s oranges.” % (amount1, amount2)
def Test2():
# New string formatting example:
amount1 = “one”
amount2 = “two”
“I have {x} apple and {y} oranges.”.format(x=amount1, y=amount2)
print('Test1: %s' %timeit.timeit(Test1, number=timeitThisNumberTimes))
print('Test2: %s' %timeit.timeit(Test2, number=timeitThisNumberTimes))
print('')
if name == ‘main’:
TimeIt_StringFormattingOldVsNew()
raw_input('Press Enter to Exit.')

TimeIt_StringFormattingOldVsNew
Test1: 0.52389039774
Test2: 1.0801278293

Results = “Old style performs faster by about 100%. Use %s for performance, not %s” %(“%”, “.format”)

_Bostjan_Mejak · July 7, 2013, 7:14pm

Then why bother to implement new string formatting if it’s so darn slow?

Your tests might be incorrect. I think this timeit module does not give accurate results, because using your code on my Windows 7 x64 box shows that the new string formatting is 80% (not 100% as in your case) slower versus the old string formatting. This discrepancy leads me to believe that the timeit module is not a bullet-proof way of testing anything. Please use another time-testing tool.

Metallicow · July 7, 2013, 10:19pm

It depends on what you want as an end result for the user. Shouldn’t have to use another tool really… The timeit module is for benchmarking python code snippets.
.format for zen: Readability counts, Beginner Learning/Coding, i18n, Small scripts that won’t be tested 1million times, etc…
%
for performance(varies a bit with py2/py3 32bitOS/64bitOS; every bit counts), Full Applications should take speed of execution into consideration(Ex: Trade printshop/authoring software, etc…), Intermediate/Advanced coders. file size(5b<= vs 12b<= per use), etc…

For small stuff, most people wouldn’t even notice the difference, but with bigger projects becomes more obvious if lots of stuff is going on in the background.
Multithreading sometimes helps alot with this, but the author has to implement it otherwise the future benefit lessens considerably. As time goes by and computers get faster and more applications hit a stopping point, then it becomes time to optimize code and look to utilize extra cores/gpu power.
Plus it is greener, and % still rocks 1st place on my raspberry Py or 1ghz oldie 32bit WinXPPro rig.

···

On Sunday, July 7, 2013 2:14:08 PM UTC-5, Boštjan Mejak wrote:

Then why bother to implement new string formatting if it’s so darn slow?

Your tests might be incorrect. I think this timeit module does not give accurate results, because using your code on my Windows 7 x64 box shows that the new string formatting is 80% (not 100% as in your case) slower versus the old string formatting. This discrepancy leads me to believe that the timeit module is not a bullet-proof way of testing anything. Please use another time-testing tool.

Tim_Roberts · July 8, 2013, 5:18pm

The new string formatting makes support for internationalization
much easier.ï¿½ Some languages need to put the operands in a different
order.ï¿½ That’s possible with the new formatting.ï¿½ It will eventually
get faster.
Honestly, dude, you need to get a clue, and you really need to start
taking a critical look at what you write before you press the “send”
key.ï¿½ Your first instinct in every situation is to blame the other
guy and insist that they make changes.ï¿½ It makes you sound
insufferable.
Instead of assuming the test is faulty, you should have done a
little reading about performance testing.ï¿½ You are running on a
different processor than the original poster.ï¿½ Your processor has
different performance characteristics and different cycle counts,
and the current load on your system means the memory and caching
behavior is different from the original poster.ï¿½ All of those things
means your numbers will almost certainly be different from ANY other
numbers.

···

Boï¿½tjan Mejak wrote:

    Then why bother to implement new string formatting

if it’s so darn slow?

      Your tests might be incorrect. I think this timeit module
does not give accurate results, because using your code on my
Windows 7 x64 box shows that the new string formatting is 80%
(not 100% as in your case) slower versus the old string
formatting. This discrepancy leads me to believe that the
timeit module is not a bullet-proof way of testing anything.
Please use another time-testing tool.

-- Tim Roberts, Providenza & Boekelheide, Inc.

timr@probo.com