[issue37945] test_locale failing

Change by Tim Lyons : -- nosy: +guy.linton ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.pytho

[issue37945] test_locale failing

Steve Dower added the comment: FYI I just closed issue10466 as a duplicate (even though that one's been around longer, this issue has more relevant information on it). -- ___ Python tracker

[issue37945] test_locale failing

Eryk Sun added the comment: If normalize() is implemented for Windows, then the tests should be split out into POSIX and Windows versions. Currently, most of the tests in NormalizeTest are not checking a result that's properly normalized for ucrt. A useful implementation of locale.normalize

[issue37945] test_locale failing

Eryk Sun added the comment: Here's some additional background information for work on this issue. A Unix locale identifier has the following form: "language[_territory][.codeset][@modifier]" | "POSIX" | "C" | "" | NULL (X/Open Portability Guide, Issue 4, 1

[issue37945] test_locale failing

Tim Golden added the comment: This feels like one of those changes where what's in place is clearly flawed but any change seems like it'll break stuff which people have had in place for years. I'll try to look at a least-breaking change but I'm honestly not sure what that would look like.

[issue37945] test_locale failing

Steve Dower added the comment: Oh man, this is too broken for me to think about today... If someone feels like writing a Windows-specific normalize() function to totally replace the Unix one, feel free, but it looks like we won't be able to get away with anything less. The "easy" change brea

[issue37945] test_locale failing

Steve Dower added the comment: > test_getsetlocale_issue1813 (test.test_locale.TestMiscellaneous) ... skipped > 'test needs Turkish locale' Yeah, looks like they're failing that part of the test. I'll run them again with the hyphen. -- ___ Python

[issue37945] test_locale failing

Eryk Sun added the comment: > None of that explains why the test doesn't seem to run at all on the > buildbots though. Are the buildbots using an older version of UCRT? BCP 47 locales used to strictly require a hyphen as the delimiter (e.g. 'tr-TR') instead of underscore (e.g. 'tr_TR'). Sup

[issue37945] test_locale failing

Steve Dower added the comment: Oh yeah, that locale_alias table is useless on Windows :( But at least the function is documented in such a way that we can change it: "The returned locale code is formatted for use with :func:`setlocale`." Alternatively, we could make setlocale() do its own no

[issue37945] test_locale failing

Eryk Sun added the comment: We get into trouble with test_getsetlocale_issue1813 because normalize() maps "tr_TR" (supported) to "tr_TR.ISO8859-9" (not supported). >>> locale.normalize('tr_TR') 'tr_TR.ISO8859-9' We should skip normalize() in Windows. It's based on a POSIX locale_alias

[issue37945] test_locale failing

Steve Dower added the comment: I pushed a custom buildbot run that only runs this test in verbose mode, and it looks like the test is being skipped some other way? https://buildbot.python.org/all/#/builders/48/builds/36 https://buildbot.python.org/all/#/builders/42/builds/54 I don't see any

[issue37945] test_locale failing

Tim Golden added the comment: I agree that that could be a fix. And certainly, if it turns out that this could never have (recently) worked as Eryk is suggesting, then let's go for it. But I still have this uneasy feeling that it's not failing on the buildbots and I can't see any sign of a s

[issue37945] test_locale failing

Steve Dower added the comment: So is the fix here to update locale._build_localename to check something like this? if encoding is None: return language elif sys.platform == 'win32' and encoding not in {'utf8', 'utf-8'}: return language else: return language + '.' + encoding -

[issue37945] test_locale failing

Eryk Sun added the comment: > But my question is, then: why is my machine failing this test [the > only one which uses this two-part locale] and not the buildbots or > (presumably) any other Windows developer? test_getsetlocale_issue1813 fails for me as well. I can't imagine how setlocale(L

[issue37945] test_locale failing

Tim Golden added the comment: Thanks, Eryk. Your explanation is as clear as always. But my question is, then: why is my machine failing this test [the only one which uses this two-part locale] and not the buildbots or (presumably) any other Windows developer? --

[issue37945] test_locale failing

Eryk Sun added the comment: local.normalize is generally wrong in Windows. It's meant for POSIX systems. Currently "tr_TR" is parsed as follows: >>> locale._parse_localename('tr_TR') ('tr_TR', 'ISO8859-9') The encoding "ISO8859-9" is meaningless to Windows. Also, the old CRT only eve

[issue37945] test_locale failing

Tim Golden added the comment: Just to save you looking, the code in https://github.com/python/cpython/blob/master/Modules/_localemodule.c#L107 converts the 2-tuple to lang.encoding form so the C module is seeing "en_GB.cp1252" -- ___ Python track

[issue37945] test_locale failing

Tim Golden added the comment: Ok; so basically this doesn't work: import locale locale.setlocale(locale.LC_CTYPE, locale.getdefaultlocale()) It gives "locale.Error: unsupported locale setting" which comes from https://github.com/python/cpython/blob/master/Modules/_localemodule.c#L107 (For

[issue37945] test_locale failing

Change by Karthikeyan Singaravelan : -- components: +Windows nosy: +eryksun, paul.moore, steve.dower, xtreak, zach.ware ___ Python tracker ___ _

[issue37945] test_locale failing

New submission from Tim Golden : On a Win10 machine I'm consistently seeing test_locale (and test__locale) fail. I'll attach pythoninfo. == ERROR: test_getsetlocale_issue1813 (test.test_locale.TestMiscellaneous) --