[Python-Dev] test__locale weirdness (original) (raw)

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