Message330380
| Author |
vstinner |
| Recipients |
ncoghlan, ned.deily, vstinner |
| Date |
2018年11月24日.23:34:24 |
| SpamBayes Score |
-1.0 |
| Marked as misclassified |
Yes |
| Message-id |
<CA+3bQGGbJtft2kLNO=JEy4XwnH=XMcu1ZOGkN7rr4GS5QUz-iw@mail.gmail.com> |
| In-reply-to |
<1543079496.26.0.788709270274.issue34589@psf.upfronthosting.co.za> |
| Content |
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... |
|