On 11 December 2016 at 08:41, Neal Gompa <ngompa13(a)gmail.com> wrote:
On Sat, Dec 10, 2016 at 3:40 PM, Zbigniew Jędrzejewski-Szmek
<zbyszek(a)in.waw.pl> wrote:
> On Sat, Dec 10, 2016 at 11:56:44PM +1000, Nick Coghlan wrote:
>> Along similar lines, what do folks think of the idea of patching
>> Python 3.6 in Fedora to assume UTF-8 if it's told that it should use
>> ASCII to communicate with the OS?
> +1
>
> Non-utf8 environments are nowadays a rarity, OTOH misconfigured
> installations which do support utf8 but are just missing an env var
> are rather common (e.g. mock).
Why aren't we fixing Fedora Cloud/Atomic and the container images to
be C.UTF-8 instead of just plain C, then?
This isn't an either/or - we can do both. The advantage of also making
a change in the Python 3.x binary is that it should be able to do the
right thing even for cases like:
================
$ LANG=C python3 -c 'import click; click.command()(lambda:None)()'
Traceback (most recent call last):
File "<string>", line 1, in <module>
File "/home/ncoghlan/.local/lib/python3.5/site-packages/click/core.py",
line 716, in __call__
return self.main(*args, **kwargs)
File "/home/ncoghlan/.local/lib/python3.5/site-packages/click/core.py",
line 675, in main
_verify_python3_env()
File
"/home/ncoghlan/.local/lib/python3.5/site-packages/click/_unicodefun.py",
line 119, in _verify_python3_env
'mitigation steps.' + extra)
RuntimeError: Click will abort further execution because Python 3 was
configured to use ASCII as encoding for the environment. Either run
this under Python 2 or consult
http://click.pocoo.org/python3/ for
mitigation steps.
This system supports the C.UTF-8 locale which is recommended.
You might be able to resolve your issue by exporting the
following environment variables:
export LC_ALL=C.UTF-8
export LANG=C.UTF-8
================
There's a reason Armin Ronacher made click apps abort outright in that
case - it really isn't recoverable from the application framework
level, as CPython will have already initialised various things
incorrectly by the time any click components get a chance to run.
However, as the distro provider, we can be both more opinionated than
the upstream CPython devs as to the correct behaviour here *and*
intervene earlier in the interpreter bootstrapping process than
library and framework developers can (i.e. before anything gets
decoded incorrectly).
While there have been a few different issues about this upstream over
the years,
http://bugs.python.org/issue28180 is the most recent one
(from a user pointing out that sys.getfilesystemencoding() gives them
the unhelpful answer of "ASCII" when running under Docker). I posted
my thoughts on what I think we should do for 3.7 at:
http://bugs.python.org/issue28180#msg282964
Cheers,
Nick.
--
Nick Coghlan | ncoghlan(a)gmail.com | Brisbane, Australia