subject:"\[issue34589\] Py_Initialize\(\) and Py_Main\(\) should not enable C locale coercion"

[issue34589] Py_Initialize() and Py_Main() should not enable C locale coercion

2019-04-07 Thread Nick Coghlan



Nick Coghlan  added the comment:

I'm inclined to leave 3.7 alone unless/until we get an actual bug report for 
the current behaviour - if an embedder finds that it just straight up doesn't 
work for them, then they can either resort to tinkering with the private APIs 
(since they won't change until Python 3.8, and at that point we expect to have 
a public API available), or else stick with Python 3.6 until later this year 
when Python 3.8 is available.

--

___
Python tracker 

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

[issue34589] Py_Initialize() and Py_Main() should not enable C locale coercion

2019-04-05 Thread STINNER Victor



STINNER Victor  added the comment:

I fixed the issue in Python 3.8 with bpo-36443:

commit d929f1838a8fba881ff0148b7fc31f6265703e3d
Author: Victor Stinner 
Date:   Wed Mar 27 18:28:46 2019 +0100

bpo-36443: Disable C locale coercion and UTF-8 Mode by default (GH-12589)

I'm not sure if it would be accceptable to the behavior in Python 3.7.x, 
especially without PEP 587 which targets Python 3.8.

--

___
Python tracker 

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

[issue34589] Py_Initialize() and Py_Main() should not enable C locale coercion

2018-12-19 Thread Nick Coghlan



Nick Coghlan  added the comment:

I still think the current Python 3.7 behaviour makes the CPython runtime a 
badly behaved C library, since we may end up changing the active libc locale 
even when it isn't the main application, and a change hasn't been explicitly 
requested by the embedding app.

However, the only way to encounter that misbehaviour is to be running a 
Unicode-unfriendly embedding application that leaves the C locale in place on a 
Unicode-unfriendly operating system that doesn't set a more sensible locale in 
the first place.

I've also gone through a few iterations on 
https://github.com/python/cpython/pull/9257 now, and respecting the -E and -I 
options *without* deferring locale coercion until the same point where UTF-8 
mode is checked for turns out to require duplication of an irritatingly large 
amount of argument processing code (as even if all you're checking for is two 
options that don't take arguments, you still need to correctly skip over all 
the other permitted arguments, stop at the arguments that terminate the python 
option list, and find the options of interest even when they're in a combined 
option string like "-vI").

Accordingly, I no longer think it's worth pursuing this change purely to 
assuage my sense of responsibility to developers of applications embedding the 
Python runtime - instead, we can leave the Python 3.7.0 solution in place for 
3.8 as well, until such time as we have embedding application authors actually 
reporting bug reports against the Python 3.7 behaviour.

To be completely honest, I expect the odds of that actually happening in 
practice to be incredibly low, and even if it does happen, our answer may well 
be to point to the in-development multi-phase configuration API rather than 
allowing it to be disabled when using Py_Initialize() and/or Py_Main().

--
resolution:  -> postponed
stage: patch review -> resolved
status: open -> closed
type:  -> behavior

___
Python tracker 

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

[issue34589] Py_Initialize() and Py_Main() should not enable C locale coercion

2018-11-28 Thread Kubilay Kocak



Change by Kubilay Kocak :


--
nosy: +koobs

___
Python tracker 

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

[issue34589] Py_Initialize() and Py_Main() should not enable C locale coercion

2018-11-24 Thread STINNER Victor

STINNER Victor added the comment:

C locale coercion is just one parameter used to select the Python
filesystem enconding. There are many others which are read later during
Python initialization, and they are inter-dependent.

https://github.com/python/cpython/blob/7f4ba4afd47f21f61de9035544809fc67d136f35/Include/coreconfig.h#L69

I don't see which problem you are trying to solve here.

For me, PYTHONCOERCECLOCALE environment variable must be ignored when -I or
-E is used, for security reasons and to get more deterministic behavior. So
I am opposed to read/enable C locale coercion earlier.

That's also why PYTHONMALLOC only change the memory allocator late in the
Python initialisation, whereas it would be simpler to read/apply the option
earlier.

For the FreeBSD CURRENT bug, I recently modified Python to use ASCII if
"force ASCII" mode is enabled. I made this change for... HP-UX! On FreeBSD,
the filesystem encoding was already ASCII in practice (FreeBSD uses Latin1
but announes ASCII!?). I am not surprised to see bugs on specific
configuration with special option (disable UTF-8 mode) :-)

I am fixing Unicode bugs on weird cased before 3.0 and we are still not
done! Recently I fixed a bug in localeconv() when LC_MONETARY uses a
different encoding than LC_CTYPE... Such config sounds like a bad choice,
but well, it "works" on Python2...

50 matches

Mail list logo