GNU Info

Info Node: (python2.1-lib.info)For extension writers and programs that embed Python

(python2.1-lib.info)For extension writers and programs that embed Python


Prev: Background Up: locale
Enter node , (file) or (file)node

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.


automatically generated by info2www version 1.2.2.9