6.22.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.