[Python-Dev] test__locale weirdness
Nick Bastin
nbastin at opnet.com
Tue Jul 13 08:26:12 CEST 2004
Brett and I spent the better part of the evening (and my morning)
trying to figure out what's making test__locale fail on MacOS X. The
test has been failing since the changes made in Modules/_localemodule.c
revision 2.46. These changes caused nl_langinfo() to return the
correct value for RADIXCHAR (among others), which it wasn't doing
before. However, now nl_langinfo(RADIXCHAR) and
localeconv()['decimal_point'] don't agree:
Take 'fr_FR' for example:
_localemodule.c:2.45:
>>> setlocale(LC_NUMERIC, 'fr_FR')
'fr_FR'
>>> nl_langinfo(RADIXCHAR)
'.'
>>> localeconv()['decimal_point']
'.'
_localemodule.c:2.46:
>>> setlocale(LC_NUMERIC, 'fr_FR')
'fr_FR'
>>> nl_langinfo(RADIXCHAR)
','
>>> localeconv()['decimal_point']
'.'
The changes made in 2.46 are closer to correct than 2.45, but we don't
understand how localeconv() is incorrect. If you stop in
PyLocale_localeconv in the debugger, you can see that the locale is
indeed set to 'fr_FR', but localeconv() has decimal_point as '.', not
comma. You could write this off as a bug in the c library, but if you
write a very basic program, it works fine:
int
main (int argc, char *argv[])
{
struct lconv *result;
if (!setlocale(LC_NUMERIC, "fr_FR")) {
printf("setlocale() failed\n");
exit(1);
}
if (!( result = localeconv() )) {
printf("localeconv() failed\n");
exit(1);
}
printf("Claimed locale:%s\n", setlocale(LC_NUMERIC, NULL));
printf("decimal point: '%s', thousands_sep: '%s'\n",
result->decimal_point,
result->thousands_sep);
return 0;
}
displays:
Claimed locale:fr_FR
decimal point: ',', thousands_sep: ''
Which is exactly what you'd expect from a working implementation. Does
anybody know what Python is doing beyond what this simple test does?
--
Nick
More information about the Python-Dev
mailing list