[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().