This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author vstinner
Recipients ncoghlan, ned.deily, vstinner
Date 2018-09-17.16:55:04
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <>
> I'd strongly prefer to just go back to the PEP 538 design. It's much simpler to implement, we don't actually want anyone turning off locale coercion except for debugging purposes (unlike UTF-8 mode), and the only argument against doing this the way PEP 538 describes is a purist one, not a practical one (which was already resolved in favour of practicality when PEP 538 was accepted).
> (...)
> That's quite a bit of code to add for the sake of a flag we don't really want anyone to ever use, though. (If it hadn't been for the debugging-CentOS-7-problems-on-Fedora issue, I doubt I would have included the off switch in PEP 538 at all)

Why did you add PYTHONCOERCECLOCALE=warn if you don't want that people use it?

> The actual functional error is that the following will currently give different outputs on Fedora and CentOS 7, whereas in the original PEP 538 implementation it would always print "C", even if locale coercion would otherwise normally work on your current platform:
>    LC_CTYPE=C PYTHONCOERCECLOCALE=0 python3 -E -c 'import os; print(os.env["LC_CTYPE"])'

You wrote that we need PYTHONCOERCECLOCALE=0 and then that we don't need it, I don't understand :-)

IMHO there are use cases where PYTHONCOERCECLOCALE=0 is important, that's why I propose to add -X coerce_c_locale=0.

There are also cases where you want the warning, so -X coerce_c_locale=warn would help as well, when -E or -I is needed.
Date User Action Args
2018-09-17 16:55:04vstinnersetrecipients: + vstinner, ncoghlan, ned.deily
2018-09-17 16:55:04vstinnersetmessageid: <>
2018-09-17 16:55:04vstinnerlinkissue34589 messages
2018-09-17 16:55:04vstinnercreate