This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Title: making Python LC_NUMERIC agnostic
Type: Stage:
Components: Interpreter Core Versions: Python 2.3
Status: closed Resolution: accepted
Dependencies: Superseder:
Assigned To: loewis Nosy List: gustavo, loewis
Priority: high Keywords: patch

Created on 2003-07-20 19:39 by gustavo, last changed 2022-04-10 16:10 by admin. This issue is now closed.

File name Uploaded Description Edit
python-lcnumeric.diff gustavo, 2003-12-04 17:40 new version, also includes changes the locale module
python-lcnumeric.diff gustavo, 2004-06-06 12:56 Updated patch; fixes %f formatter problem
Messages (11)
msg44312 - (view) Author: Gustavo J. A. M. Carneiro (gustavo) * Date: 2003-07-20 19:39
  This patch offers conversion string<->float
conversion functions that are locale agnostic.  This
way, Python will be able to run perfectly even when
LC_NUMERIC is set to something other than C.  It
happens frequently when using external modules that
these modules change LC_NUMERIC without python knowing
about it.  It will never stop happening, unfortunately,
so it is best to make python not depend on LC_NUMERIC
being always set to 'C'.
msg44313 - (view) Author: Martin v. Löwis (loewis) * (Python committer) Date: 2003-07-20 21:25
Logged In: YES 

I recommend that you do not incorporate the code of glib,
but rather arrange to link with glib (perhaps only if
activated by --with-glib). If no guaranteed-C-locale strtod
is available, the current behaviour should be preserved.
msg44314 - (view) Author: Gustavo J. A. M. Carneiro (gustavo) * Date: 2003-07-21 10:06
Logged In: YES 

  I have to incorporate glib code, otherwise what happens if
glib is not installed? It is my intention that the current
behaviour *never* be preserved.
  Well, that's not exactly an accurate statement.  What I
mean is that str() and float() should keep the current
C-locale behaviour.  
  However, underneath these python functions we could have
LC_NUMERIC set something other than 'C'.  This is vital for
some modules, like GTK+, that depend on LC_NUMERIC to be set
the locale dependent value, otherwise it behaves different
from what the user expects.
msg44315 - (view) Author: Martin v. Löwis (loewis) * (Python committer) Date: 2003-07-21 21:52
Logged In: YES 

On some systems, the desired behaviour just is not
implementable. On such systems, we should not try to
implement it by replacing the standard library. Instead, we
should just give in and not implement the feature. People
using such systems should convince their system vendors to
provide the proper API, or find out whether proper API
already exists.
msg44316 - (view) Author: Gustavo J. A. M. Carneiro (gustavo) * Date: 2003-07-22 16:26
Logged In: YES 

  If neither glib nor glibc are available, are we still
allowed to change LC_NUMERIC at will?  I want to get rid of
this problem once and for all.  The next step is to change
LC_NUMERIC to the correct locale value (or better, not
change it to 'C').
  Anyway, are you sure it's a good idea to link to glib?  Is
it a good idea to make the python interpreter depend on
glib?  Perhaps it is a bigger library than you think...
msg44317 - (view) Author: Martin v. Löwis (loewis) * (Python committer) Date: 2003-07-22 19:49
Logged In: YES 

I don't think the problem can be solved once and forall. In
fact, I'm certain that the glib code is incorrect on some
systems. For example, has it been tested on VMS, with its
three different floatin point formats?

I don't know whether linking with glib is a good idea. I'd
happily accept a patch that supports glibc only, or one that
tries for fall back to C++ std::locale on systems that
support linking C++ code into C applications. Since the bug
report was triggered through gtk problems, I expect that
these can all be solved by linking with glib - using glib on
a gtk installation should work fine.
msg44318 - (view) Author: Gustavo J. A. M. Carneiro (gustavo) * Date: 2003-09-16 21:47
Logged In: YES 

  Used James Henstridge's cleaned up code, and cleaned it up
a bit more.
msg44319 - (view) Author: Gustavo J. A. M. Carneiro (gustavo) * Date: 2004-06-03 12:08
Logged In: YES 

Any chance this can get into Python 2.4?
msg44320 - (view) Author: Martin v. Löwis (loewis) * (Python committer) Date: 2004-06-04 13:15
Logged In: YES 

The patch breaks test_coercion, if run as

python Lib/test/ test__locale test_coercion

This is because the behaviour of the %f formatter changes:

>>> import locale
>>> locale.setlocale(locale.LC_ALL,"de_DE")
>>> '%.1f' % 3.4
msg44321 - (view) Author: Gustavo J. A. M. Carneiro (gustavo) * Date: 2004-06-04 13:48
Logged In: YES 

test_coertion doesn't fail for me.  But I believe you.  I
forgot to update formatfloat in Objects/stringobject.c. 
I'll work on this over the weekend...
msg44322 - (view) Author: Martin v. Löwis (loewis) * (Python committer) Date: 2004-06-08 18:54
Logged In: YES 

Thanks for the patch. Committed as 1.145
liblocale.tex 1.36
Python.h 2.63
pystrtod.h 2.1
NEWS 1.997
_localemodule.c 2.46
cPickle.c 2.150
stropmodule.c 2.91
complexobject.c 2.71
floatobject.c 2.131
stringobject.c 2.218
compile.c 2.303
marshal.c 1.77
pystrtod.c 2.1
Date User Action Args
2022-04-10 16:10:03adminsetgithub: 38883
2003-07-20 19:39:42gustavocreate