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
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4