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

[Guido van Rossum]

On Mon, Mar 16, 2009 at 3:24 PM, Raymond Hettinger <python at rcn.com> wrote:
> [Guido van Rossum]
>>
>> Typically PEPs put the discussion of alternatives in some
>> section at the end, after the specification and other stuff relevant
>> going forward.
>
> Okay, re-arranged to make it more peppy.

>> I guess in the end this means I am in favor of Nick's alternative.
>
> Was hoping you would be more attracted to the other proposal
> which more people's needs right out of the box.  No matter
> what country you're in, it's nice to have the option to switch
> to spaces or underscores regardless of your local convention.

Your preference wasn't clear from the PEP. :-)

> In the end, most respondants seemed to support the more flexible
> version (Eric's proposal).

Well, Python survived for about 19 years without having a way to
override the decimal point *except* by using the locale module. I
guess that divides our users in two classes:

(1) Those for whom the default (C) locale is sufficient -- either
because they live in the US (1a), or because they're used to
programming languages US-centric approach (1b).

(2) Those who absolutely need their numbers formatted for a locale --
either because they want to write heavy-duty localized code (2a), or
because their locale doesn't use a comma and their end users would be
upset to see US-formatted numbers (2b).

For category (1), Nick's minimal proposal is good enough; someone in
category (1b) who can live with a US-centric decimal point can also
live with a US-centric thousands separator.

For category (2a), Eric's proposal is not good enough. Which leaves
category (2b), which must be pretty small because they've apparently
put up with using the locale module anyways.

>> One thing I don't understand: the PEP seems to exclude the 'e' and 'g'
>> format. 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?
>
> Makes sense.  So noted in the PEP.

On Mon, Mar 16, 2009 at 3:37 PM, Nick Coghlan <ncoghlan at gmail.com> wrote:
> I actually prefer proposal II as well. It provides a decent quick
> solution for one-off scripts and debugging output, while leaving proper
> l10n/i18n support to the appropriate (heavier) tools.

For debugging output and one-offs I don't think the period-vs-comma
issue matters much; I'd expect those all to fall in category (1).

Another way to look at it is: adding a thousands separator makes a
*huge* difference for a large group of potential users, because
interpreting numbers with more than 5 or 6 digits is very cumbersome
otherwise. However adding a facility to specify a different character
for the decimal point and for the separator only matters for a much
smaller group of people (2b only), and IMO isn't worth the extra
syntactic complexities. I would much rather add syntactic complexity
to address a larger issue like (2a).

I also have to say that I find Eric's proposal a bit ambiguous: why
shouldn't {:8,d} mean "insert commas between thousands"?

-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)