[Python-ideas] PEP 540: Add a new UTF-8 mode

INADA Naoki songofacandy at gmail.com
Wed Jan 11 05:15:43 EST 2017


>
>  > (I wonder if we can use LC_CTYPE=UTF-8...)
>
> Syntactically incorrect: that means the language UTF-8.
> "LC_TYPE=.UTF-8" might work, but IIRC the language tag is required,
> the region and encoding are optional.  Thus ja_JP, ja.UTF-8 are OK,
> but .UTF-8 is not.

I'm sorry.  I know it, but I'm not good at English.

I meant "I wish posix allowed LC_CTYPE=UTF-8 setting."
It's just my desire.

>
> Rant follows:
>
>  > But I dislike current situation that "people should learn how to
>  > configure locale properly, and pitfall of non-C locale, only for
>  > using UTF-8 on Python".
>
> You can use a distro that implements and defaults to the C.utf-8
> locale, and presumably you'll be OK tomorrow, well before 3.7 gets
> released.

Many people use new Python on legacy Linux which don't have C.UTF-8 locale.

I learned how to configure locale for using UTF-8 on Python.
But I don't want to force people to learn it, only for Python.


>
> Really, we're catering to users who won't set their locales properly
> and insist on old distros.  For Debian, C.utf-8 was suggested in
> 2009[1], and that RFE refers to other distros that had already
> implemented it.

CentOS 7 (and RHEL 7, maybe) seems don't provide C.UTF-8 by default.
It means C.UTF-8 is not "universal available" locale at least next 5 years.

$ cat /etc/redhat-release
CentOS Linux release 7.2.1511 (Core)
$ locale -a | grep ^C
C

>  I have all the sympathy in the world for them --
> systems *should* Just Work -- but I'm going to lean against kludges
> if they mean punishing people who actually learn about and conform to
> applicable standards (and that includes well-motivated, properly-
> documented, and carefully-implemented platform-specific extensions),
> or use systems designed by developers who do.[2]
>
> Footnotes:
> [1]  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=609306
>
> [2]  I know how bad standards can suck -- I'm a Mailman developer,
> looking at you RFC 561, er, 5322.  While I'm all for nonconformism if
> you take responsibility for any disasters that result, developers who
> conform on behalf of their users are heroes.


More information about the Python-ideas mailing list