[Python-Dev] LC_NUMERIC and C libraries (original) (raw)
Martin v. L�wis martin@v.loewis.de
16 Jul 2003 06:44:21 +0200
- Previous message: [Python-Dev] LC_NUMERIC and C libraries
- Next message: [Python-Dev] LC_NUMERIC and C libraries
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Christian Reis <kiko@async.com.br> writes:
I've spoken briefly to Guido about this, and he's suggested python-dev as the place to ask. I'd really like to know how bad "too much would break" is, and if anybody contemplates a way to fix it [*]. I'd volunteer to work on the change, of course.
I added the special-casing of LC_NUMERIC when I found Python can't parse floating point literals in Python source code anymore, in such a locale (de_DE uses the same convention). This is triggered by atof(3) changing its meaning, inside compile.c:parsenumber.
If that was fixed, it would still be the case that the float() and str() builtins would change their meaning, with potential breakage to applications and the standard library. I can't give examples for such breakage myself right now - you might just want to run the test suite and see what breaks.
However, it probably would be better if float() and str() continued to be locale-inaware.
If you can come up with a change that really allows setting LC_NUMERIC, works on all platforms, has the above properties (parsing, float, and str don't change), and passes the test suite, I'm all in favour of adding it to 2.4.
Regards, Martin
- Previous message: [Python-Dev] LC_NUMERIC and C libraries
- Next message: [Python-Dev] LC_NUMERIC and C libraries
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]