[Python-Dev] Re: Be Honest about LC_NUMERIC [REPOST]

[Tim Peters]

[Tim]
>> I'm finding it hard to believe that anyone other than me and the
>> author has actually read the patch!  It's easy to understand.

[Martin]
> On the surface, yes. However, it seems full of hidden assumptions that
> are difficult to find out and consider. For example, what if the
> platform snprintf choses to output the thousands-separator? I can't
> see how that handled in the patch.

I mentioned that one too last night -- it doesn't.

OTOH, *are* there locales that insert thousands_sep?  I don't know.  To get
thousands_sep to appear via Python's locale.format(), in all locales I've
tried so far it requires passing a true value for the optional "grouping"
argument.  Like

>>> import locale
>>> locale.setlocale(locale.LC_ALL, "german")
'German_Germany.1252'
>>> x = 12345.0
>>> locale.format("%g", x)  # no thousands_sep
'12345'
>>> locale.format("%g", x, 1)
'12.345'
>>>

Now going thru locale.py is far from going thru C, but the same thing
happens if I use sprintf() directly from C (no thousands_sep appears,
regardless of how I change locale).  That's on Win2K.  The draft std I have
handy here sez:

    LC_NUMERIC affects the decimal-point character for the
    formatted input/output functions and the string conversion
    functions, as well as the nonmonetary formatting information
    returned by the localeconv function.

There's no support there for the notion that "the formatted (etc)" functions
*can* be affected by thousands_sep, just that fiddling locale can affect
decimal-point and the (passive) values returned by localeconv().