locale.nl_langinfo(RADIXCHAR) vs locale.localeconv()['decimal_point']

[Martin v. Löwis]

Jeff Epler <jepler at unpythonic.net> writes:

> I know that Python plays some nasty games under the covers with
> LC_NUMERIC, but I would expect the "emulated" LC_NUMERIC to extend
> to locale.nl_langinfo().  

Unfortunately, this is asked too much. There are so many nl_langinfo
constants that nobody even thought of that issue (i.e. I did not think
of it :-)

> Should I file an SF bug over this, am I confused about what's going on,
> or will this likely be fixed anyway in 6.4?

Yes, no, and no. You should contribute a patch - I won't consider such
a bug worth fixing (although I readily admit it's a bug). Use the same
strategy used for localeconv, i.e. cache all relevant values at
setlocale time.

Notice that there are attempts to really reflect LC_NUMERIC in the C
library, and make Python still use the "C" locale for LC_NUMERIC where
necessary. If this is implementable (which I still doubt), then this
problem would indeed go away.

Regards,
Martin