[issue32002] test_c_locale_coercion fails when the default LC_CTYPE != "C"

Nick Coghlan added the comment: Removing issue assignment, as I'm no longer actively investigating this. -- assignee: ncoghlan -> ___ Python tracker ___

[issue32002] test_c_locale_coercion fails when the default LC_CTYPE != "C"

Nick Coghlan added the comment: New changeset 9c19b020249c451891affd81751947321a1e6957 by Nick Coghlan in branch 'master': bpo-32002: Refactor C locale coercion tests (GH-4369) https://github.com/python/cpython/commit/9c19b020249c451891affd81751947321a1e6957 --

[issue32002] test_c_locale_coercion fails when the default LC_CTYPE != "C"

Nick Coghlan added the comment: For the POSIX case, we're going to fix the implementation to always handle that the same way as it does the "C" locale: https://bugs.python.org/issue30672#msg307784 So the main question to address with the refactoring here will be capturing

[issue32002] test_c_locale_coercion fails when the default LC_CTYPE != "C"

Xavier de Gaye added the comment: > Several of the tests in test_c_locale_coercion (particularly > LocaleCoercionTests._check_c_locale_coercion) tend to assume that the system > default locale used when setting setlocale(category, "") and when all the > relevant

[issue32002] test_c_locale_coercion fails when the default LC_CTYPE != "C"

Nick Coghlan added the comment: Note: I'm not entirely sold on my own argument though, as I believe at least Alpine Linux already interprets the empty locale as C.UTF-8, so it may make more sense to use your dynamic check with both the empty string and "POSIX", and only

[issue32002] test_c_locale_coercion fails when the default LC_CTYPE != "C"

Nick Coghlan added the comment: The essential problem in both this issue and issue 30672 is that the tests are currently incorporating some Linux-specific assumptions about ways to request the "C" locale. In https://github.com/python/cpython/pull/4369, I've taken the

[issue32002] test_c_locale_coercion fails when the default LC_CTYPE != "C"

Change by Nick Coghlan : -- pull_requests: +4322 ___ Python tracker ___ ___

[issue32002] test_c_locale_coercion fails when the default LC_CTYPE != "C"

Erik Bray added the comment: In my PR there's a behavior test for the default, so we don't have to hard-code that on a per-platform basis at least. The C != POSIX thing I'm not sure you can easily test for. -- ___ Python

[issue32002] test_c_locale_coercion fails when the default LC_CTYPE != "C"

Nick Coghlan added the comment: OK, I'd been meaning to get back to refactoring those tests anyway, so assigning this to myself. I'm thinking that the right way to go will be to give the test case a more explicit model of "expected platform behaviour" (initialised in

[issue32002] test_c_locale_coercion fails when the default LC_CTYPE != "C"

Erik Bray added the comment: Yes, I looked at some of the other issues pertaining to this, but it wasn't immediately apparent how to kill multiple birds with one stone, so here I just focused on this one assumption. -- ___

[issue32002] test_c_locale_coercion fails when the default LC_CTYPE != "C"

Nick Coghlan added the comment: Issue 30672 is potentially related here - some of the test cases are already disabled on Mac OS X and other *BSD systems since the tests assume that C & POSIX are aliases of each other. I've also added Xavier to the nosy list, since the

[issue32002] test_c_locale_coercion fails when the default LC_CTYPE != "C"

Change by Erik Bray : -- keywords: +patch pull_requests: +4316 stage: -> patch review ___ Python tracker ___

[issue32002] test_c_locale_coercion fails when the default LC_CTYPE != "C"

New submission from Erik Bray : Several of the tests in test_c_locale_coercion (particularly LocaleCoercionTests._check_c_locale_coercion) tend to assume that the system default locale used when setting setlocale(category, "") and when all the relevant environment