On 16 March 2017 at 00:30, Barry Warsaw <barry at python.org> wrote: > On Mar 15, 2017, at 12:29 PM, Nick Coghlan wrote: > > >From a mainstream Linux point of view, it's not common - on > systemd-managed > >systems, for example, the only way to get the C locale these days is to > >either specify it in /etc/locale.conf, or to set it specifically in the > >environment. > > I think it's still the case that some isolation environments (e.g. Debian > chroots) default to bare C locales. Often it doesn't matter, but sometimes > tests or other applications run inside those environments will fail in ways > they don't in a normal execution environment. Yeah, I think mock (the Fedora/RHEL/CentOS build environment for RPMs) still defaults to a bare C locale, and Docker environments usually aren't systemd-managed in the first place (since PID 1 inside a container typically isn't an init system at all). The general trend for all of those seems to be "they don't use C.UTF-8... yet", though (even though some of them may not shift until the default changes at the level of the given distro's libc implementation). The answer is almost always to > explicitly coerce those environments to C.UTF-8 for Linuxes that support > that. > I also double checked that "LANG=C ./python -m test" still worked with the reference implementation. Cheers, Nick. -- Nick Coghlan | ncoghlan at gmail.com | Brisbane, Australia -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.python.org/pipermail/python-dev/attachments/20170316/b0e18fe5/attachment.html>
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4