Author barry
Recipients Jan Niklas Hasse, Sworddragon, abarry, akira, barry, ezio.melotti, inada.naoki, lemburg, ncoghlan, r.david.murray, vstinner, yan12125
Date 2017-01-05.14:44:31
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <20170105094428.25652cb9@subdivisions.wooz.org>
In-reply-to <1483614713.43.0.706506222214.issue28180@psf.upfronthosting.co.za>
Content
On Jan 05, 2017, at 11:11 AM, STINNER Victor wrote:

>I'm sure that many Linux, UNIX and BSD systems don't have the "C.UTF-8"
>locale. For example, HP-UX has "C.utf8" which is not exactly "C.UTF-8".
>
>I'm not sure that it's ok in 2017 to always force the UTF-8 encoding if the
>user locale uses a different encoding.

It's not just any different encoding, it's specifically C (implicitly,
C.ASCII).

>I proposed an opt-in option to force UTF-8: -X utf8 command line option and
>PYTHONUTF8=1 env var. Opt-in will obviously reduce the risk of backward
>compatibility issues. With an opt-in option, users are better prepared for
>mojibake issues.

If this is true, then I would like a configuration option to default this on.
As mentioned, Debian and Ubuntu already have C.UTF-8 and most environments
(although not all, see my sbuild/schroot comment earlier) will at least be
C.UTF-8.  Perhaps it doesn't matter then, but what I really want is that for
those few odd outliers (e.g. schroot), Python would act the same inside and
out those environments.  I really don't want people to have to add that envar
or switch (or even export LC_ALL) to get proper build behavior.
History
Date User Action Args
2017-01-05 14:44:31barrysetrecipients: + barry, lemburg, ncoghlan, vstinner, ezio.melotti, r.david.murray, inada.naoki, akira, Sworddragon, yan12125, abarry, Jan Niklas Hasse
2017-01-05 14:44:31barrylinkissue28180 messages
2017-01-05 14:44:31barrycreate