Message284747
| Author |
barry |
| Recipients |
Jan Niklas Hasse, abarry, akira, barry, deleted250130, ezio.melotti, lemburg, methane, 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:31 | barry | set | recipients:
+ barry, lemburg, ncoghlan, vstinner, ezio.melotti, r.david.murray, methane, akira, deleted250130, yan12125, abarry, Jan Niklas Hasse |
| 2017年01月05日 14:44:31 | barry | link | issue28180 messages |
| 2017年01月05日 14:44:31 | barry | create |
|