Solutions for LC_NUMERIC, was Re: [Python-Dev] Re: Be Honest about LC_NUMERIC [REPOST]

Gustavo J A M Carneiro gjc at
Tue Sep 16 18:04:42 EDT 2003

A Qua, 2003-09-03 às 22:32, Martin v. Löwis escreveu:
> Christian Reis <kiko at> writes:
> >     "On glibc-based systems, Python is safe from runtime changes in the
> >     LC_NUMERIC locale category. On other platforms, changing LC_NUMERIC
> >     at runtime may cause float conversion routines to fail. This may
> >     impact the Python interpreter internally."
> I could accept such a limitation. However, I maintain that the aspects
> must be fully understood, and I agree with Guido that they must be
> documented in the documentation proper (i.e. as comments in the source
> code, or the user documentation).
> So I suggest that you proceed with the PEP and the implementation
> as-is. The PEP would need to be enhanced to summarize this discussion
> (perhaps listing the alternatives that you just mentioned); the patch
> would need to be enhanced to be more simple, readable, and in the
> style of the rest of the Python source code, and would need to include
> documentation changes and test cases (although some test cases
> probably already exist).

  I have updated the patch[1], with James Henstridge's cleaned up code
(and some more cleanup).  I am aware it still needs more comments and
test cases, but interested parties might want to start looking at it.

  Please note that, after some discussion, we have concluded it is
better not to use glibc locale extensions to implement thread-safe float
conversion.  The main reasons are: (1) simplicity (no ifdefs); (2)
consistency between glibc and non-glibc platforms.   We should accept
the fact python programs should not be allowed change locale after
creating threads, period.  Perhaps python itself should raise an
exception if this is ever attempted.  This is subject to discussion, of
course! ;)



Gustavo J. A. M. Carneiro
<gjc at> <gustavo at>

More information about the Python-Dev mailing list