may cause core dumps. This makes the locale somewhat painful to use
correctly.
-Initially, when a program is started, the locale is the "C" locale, no
+Initially, when a program is started, the locale is the \samp{C} locale, no
matter what the user's preferred locale is. The program must
explicitly say that it wants the user's preferred locale settings by
calling \code{setlocale(LC_ALL, "")}.
\function{time.strftime()})), you will have to find a way to do it
without using the standard library routine. Even better is convincing
yourself that using locale settings is okay. Only as a last resort
-should you document that your module is not compatible with non-C
-locale settings.
+should you document that your module is not compatible with
+non-\samp{C} locale settings.
The case conversion functions in the
\module{string}\refstmodindex{string} and
\function{str()}.
\subsection{For extension writers and programs that embed Python}
+\label{embedding-locale}
Extension modules should never call \function{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'').
+perhaps to find out whether or not the locale is \samp{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,
-\strong{except} that the \constant{LC_NUMERIC} locale should always be
-``C''.
+\emph{except} that the \constant{LC_NUMERIC} locale should always be
+\samp{C}.
The \function{setlocale()} function in the \module{locale} module contains
gives the Python progammer the impression that you can manipulate the
-\constant{LC_NUMERIC} locale setting, but this not the case at the C
-level: C code will always find that the \constant{LC_NUMERIC} locale
-setting is ``C''. This is because too much would break when the
+\constant{LC_NUMERIC} locale setting, but this not the case at the \C{}
+level: \C{} code will always find that the \constant{LC_NUMERIC} locale
+setting is \samp{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.
+characteristics, and then restore the \samp{C} numeric locale.
When Python code uses the \module{locale} module to change the locale,
this also affect the embedding application. If the embedding
may cause core dumps. This makes the locale somewhat painful to use
correctly.
-Initially, when a program is started, the locale is the "C" locale, no
+Initially, when a program is started, the locale is the \samp{C} locale, no
matter what the user's preferred locale is. The program must
explicitly say that it wants the user's preferred locale settings by
calling \code{setlocale(LC_ALL, "")}.
\function{time.strftime()})), you will have to find a way to do it
without using the standard library routine. Even better is convincing
yourself that using locale settings is okay. Only as a last resort
-should you document that your module is not compatible with non-C
-locale settings.
+should you document that your module is not compatible with
+non-\samp{C} locale settings.
The case conversion functions in the
\module{string}\refstmodindex{string} and
\function{str()}.
\subsection{For extension writers and programs that embed Python}
+\label{embedding-locale}
Extension modules should never call \function{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'').
+perhaps to find out whether or not the locale is \samp{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,
-\strong{except} that the \constant{LC_NUMERIC} locale should always be
-``C''.
+\emph{except} that the \constant{LC_NUMERIC} locale should always be
+\samp{C}.
The \function{setlocale()} function in the \module{locale} module contains
gives the Python progammer the impression that you can manipulate the
-\constant{LC_NUMERIC} locale setting, but this not the case at the C
-level: C code will always find that the \constant{LC_NUMERIC} locale
-setting is ``C''. This is because too much would break when the
+\constant{LC_NUMERIC} locale setting, but this not the case at the \C{}
+level: \C{} code will always find that the \constant{LC_NUMERIC} locale
+setting is \samp{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.
+characteristics, and then restore the \samp{C} numeric locale.
When Python code uses the \module{locale} module to change the locale,
this also affect the embedding application. If the embedding
projects / python / commitdiff