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
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4