[Python-ideas] Rough draft: Proposed format specifier for a thousands separator (discussion moved from python-dev)
tjreedy at udel.edu
Tue Mar 17 01:01:53 CET 2009
Guido van Rossum wrote:
> On Mon, Mar 16, 2009 at 12:19 PM, Raymond Hettinger <python at rcn.com> wrote:
>> The conversation on the thousands separator seems to have wound down
>> and the PEP has stabilized: http://www.python.org/dev/peps/pep-0378/
>> Please pronounce.
> That's not a PEP, it's just a summary of a discussion without any
> choice. :-)
I hope Raymond can understand this. To me, the choice presented is to
add the Main Proposal syntax extension, or not.
Typically PEPs put the discussion of alternatives in some
> section at the end, after the specification and other stuff relevant
> going forward.
You want more alternatives than the Nick's Alternative Proposal,
discussed at the end? I believe most of the other ideas on the list
were directed at some sense of (b) below.
> Just to add more fuel to the fire, did anyone propose refactoring the
> problem into (a) a way to produce output with a thousands separator,
> and (b) a way to localize formats?
Since a way to produce output with a choice of thousands separators is a
necessary part of a way localize formats, I am not sure of what
distinction you are trying to draw.
'Localize formats' has two quite distinct meanings: 'format this number
in a particular way (which can vary from number to number or at least
user to user)' versus 'format all numbers according to a particular
> We could solve (a) by adding a
> comma to all numeric format languages along Nick's proposal,
Raymond current proposal, based on discussion, is to offer users a
choice of 5 chars as thousands separators (and allow a choice of decimal
separator). Nick's proposal is to only offer comma as thousands
separator. While the latter meets my current parochial needs, I favor
the more inclusive approach.
> and we could solve (b) either now
Raymond's main proposal partially solves that now (which is to say,
completely solves than now for most of the world) in the first sense I
gave for (b), on a case-by-case basis.
> or later by adding some other flag that
> means "use locale-specific numeric formatting for this value".
As I understand from Raymond's introductory comments and those in the
locale module docs, the global C locale setting is not intended to be
changed on an output-by-output basis. Hence, while useful for
nationalizing software, it is not so useful for individualized output
from global software.
> perhaps there could be two separate flags corresponding to the
> grouping and monetary arguments to locale.format().
The flags just say to use the global locale settings, which have the
limitations indicated above. Raymond's proposal is that a Python
programmer should be better able to say "Format this number how I (or a
particular user) want it to be formatted, regardless of the 'locale'
> I'd be happy to punt on (b) until later.
> This is somewhat analogous to the approach for strftime() which has
> syntax to invoke locale-specific formatting (%a, %A, %b, %B, %c, %p,
> %x, %X).
With the attendant pluses and minuses.
> I guess in the end this means I am in favor of Nick's alternative.
I fail to see how this follows from your previous comments.
> One thing I don't understand: the PEP seems to exclude the 'e' and 'g'
Both proposals claim to include e and g. However, since thousands
separators only apply to the left of the decimal point, and e notation
only has one digit to the left, no thousands separator proposal will
apply the e (and g when it produces e). The only known separator used
to the left is a space, typically in groups of 5 digits, in some math
tables. The decimal separator part of the PEP *does* apply to e and g.
> I would think that in case 'g' defers to 'f' it should act the
> same, and in case it defers to 'e', well, in the future (under (b)
> above) that could still change the period into a comma, right?
With the main proposal, one could simply specify, for instance, '8,1f'
instead of '8.1f' to make that change *now*. I consider that much
better than post-processing, which Nick's alternative would continue to
require, and which gets worse with thousands separators added.
Terry Jan Reedy
More information about the Python-ideas