Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

making Python LC_NUMERIC agnostic #38883

Closed
gustavo mannequin opened this issue Jul 20, 2003 · 11 comments
Closed

making Python LC_NUMERIC agnostic #38883

gustavo mannequin opened this issue Jul 20, 2003 · 11 comments
Assignees
@loewis
Labels
interpreter-core (Objects, Python, Grammar, and Parser dirs)

Comments

@gustavo
Copy link
Mannequin

gustavo mannequin commented Jul 20, 2003

BPO 774665
Nosy @loewis
Files
  • python-lcnumeric.diff: new version, also includes changes the locale module
  • python-lcnumeric.diff: Updated patch; fixes %f formatter problem
    		•

    Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.

    Show more details

    GitHub fields:

    assignee = 'https://github.com/loewis'
closed_at = <Date 2004-06-08.18:54:04.000>
created_at = <Date 2003-07-20.19:39:42.000>
labels = ['interpreter-core']
title = 'making Python LC_NUMERIC agnostic'
updated_at = <Date 2004-06-08.18:54:04.000>
user = 'https://bugs.python.org/gustavo'

    bugs.python.org fields:

    activity = <Date 2004-06-08.18:54:04.000>
actor = 'loewis'
assignee = 'loewis'
closed = True
closed_date = None
closer = None
components = ['Interpreter Core']
creation = <Date 2003-07-20.19:39:42.000>
creator = 'gustavo'
dependencies = []
files = ['5482', '5483']
hgrepos = []
issue_num = 774665
keywords = ['patch']
message_count = 11.0
messages = ['44312', '44313', '44314', '44315', '44316', '44317', '44318', '44319', '44320', '44321', '44322']
nosy_count = 2.0
nosy_names = ['loewis', 'gustavo']
pr_nums = []
priority = 'high'
resolution = 'accepted'
stage = None
status = 'closed'
superseder = None
type = None
url = 'https://bugs.python.org/issue774665'
versions = ['Python 2.3']
    @gustavo
    Copy link
    Mannequin Author

    gustavo mannequin commented Jul 20, 2003

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

    @gustavo gustavo mannequin closed this as completed Jul 20, 2003
    @gustavo gustavo mannequin assigned loewis Jul 20, 2003
    @gustavo gustavo mannequin added the interpreter-core (Objects, Python, Grammar, and Parser dirs) label Jul 20, 2003
    @gustavo gustavo mannequin closed this as completed Jul 20, 2003
    @gustavo gustavo mannequin assigned loewis Jul 20, 2003
    @gustavo gustavo mannequin added the interpreter-core (Objects, Python, Grammar, and Parser dirs) label Jul 20, 2003
    @loewis
    Copy link
    Mannequin

    loewis mannequin commented Jul 20, 2003

    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.

    @gustavo
    Copy link
    Mannequin Author

    gustavo mannequin commented Jul 21, 2003

    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.

    @loewis
    Copy link
    Mannequin

    loewis mannequin commented Jul 21, 2003

    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.

    @gustavo
    Copy link
    Mannequin Author

    gustavo mannequin commented Jul 22, 2003

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

    @loewis
    Copy link
    Mannequin

    loewis mannequin commented Jul 22, 2003

    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.

    @gustavo
    Copy link
    Mannequin Author

    gustavo mannequin commented Sep 16, 2003

    Logged In: YES
    user_id=908

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

    @gustavo
    Copy link
    Mannequin Author

    gustavo mannequin commented Jun 3, 2004

    Logged In: YES
    user_id=908

    Any chance this can get into Python 2.4?

    @loewis
    Copy link
    Mannequin

    loewis mannequin commented Jun 4, 2004

    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'

    @gustavo
    Copy link
    Mannequin Author

    gustavo mannequin commented Jun 4, 2004

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

    @loewis
    Copy link
    Mannequin

    loewis mannequin commented Jun 8, 2004

    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

    @ezio-melotti ezio-melotti transferred this issue from another repository Apr 9, 2022
    Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
    Assignees

    @loewis loewis

    Labels
    interpreter-core (Objects, Python, Grammar, and Parser dirs)
    Projects
    None yet
    Milestone
    No milestone
    Development

    No branches or pull requests
    0 participants