[Python-ideas] Rough draft: Proposed format specifier for a thousands separator (discussion moved from python-dev)

[Terry Reedy]

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 
national standard'.

 > 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' 
setting".

 > 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'
> format.

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