[Patches] [ python-Patches-774665 ] making Python LC_NUMERIC agnostic

Tue Jun 8 14:54:04 EDT 2004

Patches item #774665, was opened at 2003-07-20 21:39
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=774665&group_id=5470

Category: Core (C code)
Group: Python 2.3
>Status: Closed
>Resolution: Accepted
Priority: 7
Submitted By: Gustavo J. A. M. Carneiro (gustavo)
Assigned to: Martin v. Löwis (loewis)
Summary: making Python LC_NUMERIC agnostic

Initial Comment:
  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'.

----------------------------------------------------------------------

>Comment By: Martin v. Löwis (loewis)
Date: 2004-06-08 20:54

Message:
Logged In: YES 
user_id=21627

Thanks for the patch. Committed as

Makefile.pre.in 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

----------------------------------------------------------------------

Comment By: Gustavo J. A. M. Carneiro (gustavo)
Date: 2004-06-04 15:48

Message:
Logged In: YES 
user_id=908

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

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2004-06-04 15:15

Message:
Logged In: YES 
user_id=21627

The patch breaks test_coercion, if run as

python Lib/test/regrtest.py test__locale test_coercion

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

>>> import locale
>>> locale.setlocale(locale.LC_ALL,"de_DE")
'de_DE'
>>> '%.1f' % 3.4
'3,4'

----------------------------------------------------------------------

Comment By: Gustavo J. A. M. Carneiro (gustavo)
Date: 2004-06-03 14:08

Message:
Logged In: YES 
user_id=908

Any chance this can get into Python 2.4?

----------------------------------------------------------------------

Comment By: Gustavo J. A. M. Carneiro (gustavo)
Date: 2003-09-16 23:47

Message:
Logged In: YES 
user_id=908

  Used James Henstridge's cleaned up code, and cleaned it up
a bit more.

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2003-07-22 21:49

Message:
Logged In: YES 
user_id=21627

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.

----------------------------------------------------------------------

Comment By: Gustavo J. A. M. Carneiro (gustavo)
Date: 2003-07-22 18:26

Message:
Logged In: YES 
user_id=908

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

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2003-07-21 23:52

Message:
Logged In: YES 
user_id=21627

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.

----------------------------------------------------------------------

Comment By: Gustavo J. A. M. Carneiro (gustavo)
Date: 2003-07-21 12:06

Message:
Logged In: YES 
user_id=908

  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.

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2003-07-20 23:25

Message:
Logged In: YES 
user_id=21627

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.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=774665&group_id=5470