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][color=blue][color=green][color=darkred]
>>> import locale
>>> locale.setlocale(locale.LC_ALL, "fr_FR")[/color][/color][/color]
'fr_FR'[color=blue][color=green][color=darkred]
>>> locale.nl_langinfo(locale.DAY_1)[/color][/color][/color]
'dimanche'[color=blue][color=green][color=darkred]
>>> # Okay, we *are* in France now
>>> locale.localeconv()['decimal_point'][/color][/color][/color]
','[color=blue][color=green][color=darkred]
>>> # Yep, they use this in place of the decimal point
>>> locale.nl_langinfo(locale.RADIXCHAR)[/color][/color][/color]
'.'[color=blue][color=green][color=darkred]
>>> # But not if you use nl_langinfo() !?[/color][/color][/color]

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

Jeff

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

Jeff Epler <jepler@unpythonic.net> writes:
[color=blue]
> 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().[/color]

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 :-)
[color=blue]
> 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?[/color]

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

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

Martin,
Thanks for the feedback. I've created the bug on SF:
http://python.org/sf/798145

Jeff