6.26.2 For extension writers and programs that embed 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.
|
