[issue30647] CODESET error on AMD64 FreeBSD 10.x Shared 3.x caused by the PEP 538

Nick Coghlan added the comment: I was able to fix the test_readline failure by restoring the locale based on the environment settings with `setlocale(LC_CTYPE, "")` rather than the return value from a preceding call to `setlocale(LC_CTYPE, NULL)`. That means we can leave the runtime coercion

[issue30647] CODESET error on AMD64 FreeBSD 10.x Shared 3.x caused by the PEP 538

Nick Coghlan added the comment: New changeset 18974c35ad9d25ffea041dc0363dc01889f4a595 by Nick Coghlan in branch 'master': bpo-30647: Check nl_langinfo(CODESET) in locale coercion (GH-2374) https://github.com/python/cpython/commit/18974c35ad9d25ffea041dc0363dc01889f4a595 --

[issue30647] CODESET error on AMD64 FreeBSD 10.x Shared 3.x caused by the PEP 538

Nick Coghlan added the comment: Current status of the PR: - testing suggests that "nl_langinfo(CODESET)" fails with LC_CTYPE=UTF-8 on Mac OS X as well, but that doesn't matter for Python start-up, since we hardcode UTF-8 as the locale encoding and never call nl_langinfo - on Linux however,

[issue30647] CODESET error on AMD64 FreeBSD 10.x Shared 3.x caused by the PEP 538

Changes by Nick Coghlan : -- pull_requests: +2421 ___ Python tracker ___ ___

[issue30647] CODESET error on AMD64 FreeBSD 10.x Shared 3.x caused by the PEP 538

Changes by Nick Coghlan : -- assignee: -> ncoghlan ___ Python tracker ___ ___

[issue30647] CODESET error on AMD64 FreeBSD 10.x Shared 3.x caused by the PEP 538

Nick Coghlan added the comment: Note that the coercion logic includes a runtime check to see if 'setlocale(LC_CTYPE, "")' succeeds. That's how we skip over the non-existent C.UTF-8 and C.utf8 to get to "LC_CTYPE=UTF-8" on Mac OS X and FreeBSD. That *appears* to work (and really does work on

[issue30647] CODESET error on AMD64 FreeBSD 10.x Shared 3.x caused by the PEP 538

bapt added the comment: More details here: C.UTF-8 is a glibc only thing: https://sourceware.org/glibc/wiki/Proposals/C.UTF-8 not even mainstream. The closest thing to a C locale with unicode would be to set everything to locale C but LC_CTYPE which would be set to en_US.UTF-8. The problem

[issue30647] CODESET error on AMD64 FreeBSD 10.x Shared 3.x caused by the PEP 538

Ned Deily added the comment: macOS is also BSD-like with regard to locales: it also does not have any C.* locales other than plain C. See, for example, the discussion at bpo-18378. -- nosy: +ned.deily ___ Python tracker

[issue30647] CODESET error on AMD64 FreeBSD 10.x Shared 3.x caused by the PEP 538

bapt added the comment: Per POSIX, the C locale is only expected to be ASCII. C.UTF-8 is a linux only thing (actually I thought it was a debian only thing, but maybe not). I was thinking about creating a C.utf8 locale on FreeBSD but it is not that simple to do (still doable and an interesting

[issue30647] CODESET error on AMD64 FreeBSD 10.x Shared 3.x caused by the PEP 538

Changes by STINNER Victor : -- nosy: +koobs ___ Python tracker ___ ___

[issue30647] CODESET error on AMD64 FreeBSD 10.x Shared 3.x caused by the PEP 538

STINNER Victor added the comment: On my FreeBSD 11 VM, I only have the "C" locale, not "UTF-8 C" locale: [haypo@freebsd ~/prog/python/master]$ locale -a|grep ^C C But CPython still asks me to use a non existent locale (newlines added for readability): [haypo@freebsd ~/prog/python/master]$

[issue30647] CODESET error on AMD64 FreeBSD 10.x Shared 3.x caused by the PEP 538

New submission from STINNER Victor: Regression caused by the commit 6ea4186de32d65b1f1dc1533b6312b798d300466, bpo-28180: Implementation for PEP 538. http://buildbot.python.org/all/builders/AMD64%20FreeBSD%2010.x%20Shared%203.x/builds/412/steps/compile/logs/stdio Python detected LC_CTYPE=C: