----------------------------------------
> From: steve+comp.lang.pyt...@pearwood.info
> Subject: Re: PEP 378: Format Specifier for Thousands Separator
> Date: Wed, 22 May 2013 03:08:54 +0000
> To: python-list@python.org
[...]
>> So, the only alternative to have "'%,d' % x" rendering the thousands
>> separator output would a C source code modification?
>
> That's one alternative. But the language you would be then running will
> no longer be Python.
>
> Another alternative would be to write a pre-processor that parses your
> Python source code, extracts any reference to the above, and replaces it
> with a call to the appropriate format call. But not only is that a lot of
> work for very little gain, but it's also more or less impossible to do in
> full generality. And again, what you are running will be something
> different than Python, it will be Python plus a pre-processor.
>
>
> Don't fight the language. You will lose.
Not fighting the language. In fact it's not even a language issue.
All I need is a standard library[1] improvement: "%,d"! That's all!
Just to put in perspective the performance difference of str.__mod__() and
str.format():
C:\Python27>python -m timeit -cv -n10000000 "'%d'%12345"
raw times: 0.386 0.38 0.373
10000000 loops, best of 3: 0.0373 usec per loop
C:\Python27>python -m timeit -cv -n10000000 "'{:d}'.format(12345)"
raw times: 7.91 7.89 7.98
10000000 loops, best of 3: 0.789 usec per loop
C:\Python27>python -m timeit -cv -n10000000 "'{:,d}'.format(12345)"
raw times: 8.7 8.67 8.78
10000000 loops, best of 3: 0.867 usec per loop
That shows str.format() is 20 times slower than str.__mod__() for a simple
decimal integer literal formatting.
And it's additionally 10% slower if the thousands separator format specifier
(',') is used.
[1] I think that translates to Python source code in 'Objects/stringobject.c'
and maybe 'Objects/unicodeobject.c'
>
>
> --
> Steven
> --
> http://mail.python.org/mailman/listinfo/python-list
>
--
http://mail.python.org/mailman/listinfo/python-list
