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...
History
Date User Action Args
2018-11-24 23:34:24vstinnersetrecipients: + vstinner, ncoghlan, ned.deily
2018-11-24 23:34:24vstinnerlinkissue34589 messages
2018-11-24 23:34:24vstinnercreate