Message325493
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) |
|
Date |
User |
Action |
Args |
2018-09-16 15:02:07 | ncoghlan | set | recipients:
+ ncoghlan, vstinner, ned.deily |
2018-09-16 15:02:07 | ncoghlan | set | messageid: <1537110127.46.0.956365154283.issue34589@psf.upfronthosting.co.za> |
2018-09-16 15:02:07 | ncoghlan | link | issue34589 messages |
2018-09-16 15:02:07 | ncoghlan | create | |
|