[Python-ideas] Rough draft: Proposed format specifier for a thousands separator (discussion moved from python-dev)
Guido van Rossum
guido at python.org
Tue Mar 17 03:06:30 CET 2009
Our emails crossed.
On Mon, Mar 16, 2009 at 5:01 PM, Terry Reedy <tjreedy at udel.edu> wrote:
> Guido van Rossum wrote:
>> On Mon, Mar 16, 2009 at 12:19 PM, Raymond Hettinger <python at rcn.com>
>>> 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
>> 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
>> 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'
> 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
> Python-ideas mailing list
> Python-ideas at python.org
--Guido van Rossum (home page: http://www.python.org/~guido/)
More information about the Python-ideas