[Python-Dev] test__locale weirdness

[Nick Bastin]

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