locale.nl_langinfo(RADIXCHAR) vs locale.localeconv()['decimal_point']
I'd expect these two to be identical, but they don't seem to be.
[This session from 2.2.2 on RedHat Linux 9; same behavior in 2.3b1]
>>> import locale
>>> locale.setlocale(locale.LC_ALL, "fr_FR")
>>> # Okay, we *are* in France now
>>> # Yep, they use this in place of the decimal point
>>> # But not if you use nl_langinfo() !?
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(). The documentation (doc/lib/module-locale.html
or pydoc locale) doesn't reflect this limitation of nl_langinfo() as
far as I can tell.
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? It's not a pressing need
for me, since code can just use localeconv() anyway (or locale.atof and
friends, for that matter)...
Martin v. =?iso-8859-15?q?L=F6wis?=
Jeff Epler <(E-Mail Removed)> 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
> 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
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.