Issue 774665: making Python LC_NUMERIC agnostic (original) (raw)

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

Files
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 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.
msg44314 - (view) Author: Gustavo J. A. M. Carneiro (gustavo) * Date: 2003-07-21 10:06
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.
msg44315 - (view) Author: Martin v. Löwis (loewis) * (Python committer) Date: 2003-07-21 21:52
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.
msg44316 - (view) Author: Gustavo J. A. M. Carneiro (gustavo) * Date: 2003-07-22 16:26
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...
msg44317 - (view) Author: Martin v. Löwis (loewis) * (Python committer) Date: 2003-07-22 19:49
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.
msg44318 - (view) Author: Gustavo J. A. M. Carneiro (gustavo) * Date: 2003-09-16 21:47
Logged In: YES user_id=908 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 user_id=908 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 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'
msg44321 - (view) Author: Gustavo J. A. M. Carneiro (gustavo) * Date: 2004-06-04 13:48
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...
msg44322 - (view) Author: Martin v. Löwis (loewis) * (Python committer) Date: 2004-06-08 18:54
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
History
Date User Action Args
2022-04-10 16:10:03 admin set github: 38883
2003-07-20 19:39:42 gustavo create