On 11 December 2016 at 08:41, Neal Gompa <[email protected]> wrote:
> On Sat, Dec 10, 2016 at 3:40 PM, Zbigniew Jędrzejewski-Szmek
> <[email protected]> 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 | [email protected] | Brisbane, Australia
_______________________________________________
python-devel mailing list -- [email protected]
To unsubscribe send an email to [email protected]
