Author ncoghlan
Recipients ncoghlan, ned.deily, vstinner
Date 2018-09-16.15:02:07
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1537110127.46.0.956365154283.issue34589@psf.upfronthosting.co.za>
In-reply-to
Content
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).

However, if you were willing to do the updates on my PR branch to implement it, then I'd accept an alternative that added a pass through the command line arguments that checks for at least one of the two following cases after a legacy locale has been detected:

- the new option "-X coerce_c_locale=0" (ASCII) is present in the arg list
- neither "-E" nor "-I" (ASCII) are present in the arg list, and PYTHONCOERCECLOCALE is not set to zero

The code that sets warn_on_c_locale in the core config would then look for `-X coerce_c_locale=warn` in addition to looking for `PYTHONCOERCECLOCALE=warn`.

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)
History
Date User Action Args
2018-09-16 15:02:07ncoghlansetrecipients: + ncoghlan, vstinner, ned.deily
2018-09-16 15:02:07ncoghlansetmessageid: <1537110127.46.0.956365154283.issue34589@psf.upfronthosting.co.za>
2018-09-16 15:02:07ncoghlanlinkissue34589 messages
2018-09-16 15:02:07ncoghlancreate