Guido van Rossum wrote:
On Mon, Mar 16, 2009 at 12:19 PM, Raymond Hettinger <python@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