[issue34639] PYTHONCOERCECLOCALE is ignored when using -E or -I option

[STINNER Victor]

STINNER Victor  added the comment:

The discussion moved back to bpo-34589.

--
resolution:  -> duplicate
stage:  -> resolved
status: open -> closed
superseder:  -> Py_Initialize() and Py_Main() should not enable C locale 
coercion

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue34639] PYTHONCOERCECLOCALE is ignored when using -E or -I option

[STINNER Victor]

STINNER Victor  added the comment:

> Respecting -E and -I isn't a problem per se - the problem is moving the 
> _Py_CoerceLegacyLocale call to a point that's incredibly late in the startup 
> process *just* to get it to respect those flags.

Would you mind to elaborate how it is an issue? The LC_CTYPE is coerced 
*before* the configuration is read a second time. If there is an issue, would 
you mind to show an example where something is decoded from the wrong encoding?

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue34639] PYTHONCOERCECLOCALE is ignored when using -E or -I option

[Nick Coghlan]

Nick Coghlan  added the comment:

For the PYTHONCOERCECLOCALE=warn case, it turns out that my preferred approach 
to implementing bpo-34589 also naturally ends up respecting -I and -E for that 
(i.e. supplying -I or -E will suppressed the warning).

However, my upcoming PR for that also reinstates and expands on my original 
comment that explained why it was valuable to support "PYTHONCOERCECLOCALE=0 
python3 -E ..." and "PYTHONCOERCECLOCALE=0 python3 -I ...": so you can readily 
reproduce the way that locale coercion behaves on a platform *without* a 
suitable target locale (e.g. CentOS 7), even if your current platform actually 
does have such a locale available (e.g. Fedora).

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue34639] PYTHONCOERCECLOCALE is ignored when using -E or -I option

[Nick Coghlan]

Nick Coghlan  added the comment:

Respecting -E and -I isn't a problem per se - the problem is moving the 
_Py_CoerceLegacyLocale call to a point that's incredibly late in the startup 
process *just* to get it to respect those flags.

I don't actually mind if you reinstate the extra pass through the command line 
arguments just to check for -E and -I early enough for it to affect a properly 
located call to _Py_CoerceLegacyLocale, I just don't think it's necessary to do 
so.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue34639] PYTHONCOERCECLOCALE is ignored when using -E or -I option

[STINNER Victor]

Change by STINNER Victor :


--
nosy: +ncoghlan

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue34639] PYTHONCOERCECLOCALE is ignored when using -E or -I option

[STINNER Victor]

New submission from STINNER Victor :

I modified Py_Main() to ignore the PYTHONCOERCECLOCALE environment variable if 
-E or -I command line option is used. But Nick asks to always read 
PYTHONCOERCECLOCALE.

We should either update the PEP or change the code.

I am not sure why PYTHONCOERCECLOCALE should be handled differently than other 
PYTHON* variable like PYTHONWARNINGS or PYTHONUTF8. Is it because it impacts 
the encodings? Is it because there was a chicken-and-egg issue before I 
reworked Py_Main() code? (PYTHONCOERCECLOCALE env var was read before reading 
command line arguments.)

--

Copy of Nick Coghlan's msg325009:

(The one exception to "nothing gets decoded incorrectly" is that 
PYTHONCOERCECLOCALE itself is always interpreted as an ASCII field: the values 
that it checks for are actually ASCII byte sequences, not Unicode code points.

The documentation could definitely be much clearer on that point though, as 
even in the PEP it's only implied by the final paragraph in 
https://www.python.org/dev/peps/pep-0538/#legacy-c-locale-coercion-in-the-standalone-python-interpreter-binary
 which is mostly talking about the fact that this particular environment 
variable is still checked, even if you pass the -I or -E command line options.

--
components: Interpreter Core
messages: 325096
nosy: vstinner
priority: normal
severity: normal
status: open
title: PYTHONCOERCECLOCALE is ignored when using -E or -I option
versions: Python 3.7, Python 3.8

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com