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

[SourceForge.net]

Patches item #774665, was opened at 2003-07-20 20:39
Message generated for change (Comment added) made by gustavo
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: Open
Resolution: None
Priority: 5
Submitted By: Gustavo J. A. M. Carneiro (gustavo)
Assigned to: Nobody/Anonymous (nobody)
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: Gustavo J. A. M. Carneiro (gustavo)
Date: 2003-09-16 22: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 20: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 17: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 22: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 11: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 22: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