[Python-Dev] Re: Be Honest about LC_NUMERIC [REPOST] (original) (raw)
Tim Peters tim.one at comcast.net
Tue Sep 2 12:29:55 EDT 2003
- Previous message: [Python-Dev] Re: Be Honest about LC_NUMERIC [REPOST]
- Next message: [Python-Dev] Re: Be Honest about LC_NUMERIC [REPOST]
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
[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.LCALL, "german") 'German_Germany.1252' x = 12345.0 locale.format("%g", x) # no thousandssep '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().
- Previous message: [Python-Dev] Re: Be Honest about LC_NUMERIC [REPOST]
- Next message: [Python-Dev] Re: Be Honest about LC_NUMERIC [REPOST]
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]