 |
 |
 |
Referencia de la Biblioteca de Python |  |
 |
 |
|
|
|
Referencia de la Biblioteca de Python | |
|
|
Extension modules should never call setlocale(), except to find out what the current locale is. But since the return value can only be used portably to restore it, that is not very useful (except perhaps to find out whether or not the locale is "C").
When Python is embedded in an application, if the application sets the locale to something specific before initializing Python, that is generally okay, and Python will use whatever locale is set, except that the LC_NUMERIC locale should always be "C".
The setlocale() function in the locale module gives the Python programmer the impression that you can manipulate the LC_NUMERIC locale setting, but this not the case at the C level: C code will always find that the LC_NUMERIC locale setting is "C". This is because too much would break when the decimal point character is set to something else than a period (e.g. the Python parser would break). Caveat: threads that run without holding Python's global interpreter lock may occasionally find that the numeric locale setting differs; this is because the only portable way to implement this feature is to set the numeric locale settings to what the user requests, extract the relevant characteristics, and then restore the "C" numeric locale.
When Python code uses the locale module to change the locale, this also affects the embedding application. If the embedding application doesn't want this to happen, it should remove the _locale extension module (which does all the work) from the table of built-in modules in the config.c file, and make sure that the _locale module is not accessible as a shared library.
|
|
|
Referencia de la Biblioteca de Python | |
|
|