On 12 December 2016 at 16:18, Thomas Spura <tomspur(a)fedoraproject.org> wrote:
Zbigniew Jędrzejewski-Szmek <zbyszek(a)in.waw.pl> schrieb am Mo.,
12. Dez.
2016, 02:59:
> To make things less hand-wavy: there are concrete examples where this
> would be known to help: containers as mentioned in the original
> proposal, and mock (in my experience tests most often require setting
> an utf-8 environment to work). Do we know of examples where the
> proposed change would make things worse?
I don't and didn't when this change was dropped a few years ago... It would
certainly help to discuss this also upstream and if there is no objection,
implement Nick's proposal.
I don't anticipate any major concerns with downstream redistributors
adding this behaviour, as the main thing that makes us nervous about
globally changing the default upstream is the sheer variety of Linux
distros out there, and the fact that folks are inclined to take their
Linux integration bugs straight to
bugs.python.org rather than first
trying the issue tracker for their particular distro.
By contrast, for the Fedora system Python, we only need to worry about
doing what's right for *Fedora 26+*, which is a much more constrained
environment than "arbitrary versions of arbitrary Linux distributions
running arbitrary init systems".
Specifically:
- we know that the C.UTF-8 locale should always be available
- we know that system applications don't intentionally use the C locale
- we know that some popular Python libraries will explicitly fail if
you try to use the C locale with Python 3
- we know that anyone trying to use the C locale with a non-UTF-8
default locale already has other problems
- we know that (containers aside) systemd is pretty good about setting
the locale appropriately based on /etc/locale.conf
That lets us pursue a simpler version of the idea that can ignore some
failure modes (like "C.UTF-8" being unavailable).
As far as where we might add that check, I'd suggest the entry point
for the `python3` binary itself, rather than in the shared library:
https://hg.python.org/cpython/file/3.6/Programs/python.c#l46
At various points during start-up CPython uses 'setlocale(LC_ALL, "")'
to force itself back into the default locale for the process based on
its environment, so the locale injection would need to look something
like:
char *loc = setlocale(LC_CTYPE, NULL);
if (loc != NULL && strcmp(loc, "C") == 0) {
setenv("LC_ALL", "C.UTF-8", 1);
setenv("LANG", "C.UTF-8", 1);
}
(Plus error checking and the warning on stderr that this was being done)
I guess the next step would be for me to try this in a local clone,
and see what happens when running "LANG=C ./python -m regrtest" as
well as when running click.
Cheers,
Nick.
--
Nick Coghlan | ncoghlan(a)gmail.com | Brisbane, Australia