Message361830
| Author |
eryksun |
| Recipients |
eryksun, paul.moore, steve.dower, terry.reedy, tim.golden, vstinner, zach.ware |
| Date |
2020年02月11日.19:36:49 |
| SpamBayes Score |
-1.0 |
| Marked as misclassified |
Yes |
| Message-id |
<1581449809.49.0.567352273734.issue38324@roundup.psfhosted.org> |
| In-reply-to |
| Content |
It is not a duplicate of bpo-37945. The tests in test/test__locale.py need to be fixed to work with Windows.
In msg354021, I discussed the problem reported with test_lc_numeric_localeconv. The "ps_AF" (Pashto, Afghanistan) item in known_numerics has to be skipped in Windows because the system data does not agree with the test's assumed Arabic decimal and thousands separator, U+066B and U+066C, but instead uses "," and ".".
Also, all tests need to swap the order of setting LC_NUMERIC and LC_CTYPE in order to avoid a UnicodeDecodeError with locales that use UTF-8, such as "ka_GE". _locale.localeconv should be using the wide-character_W_ prefixed string fields from the lconv structure in Windows [1], such as _W_decimal_point. Until that gets fixed, tests need to be mindful that ucrt in Windows uses the current LC_CTYPE to update the multibyte strings in the lconv structure when setting LC_NUMERIC. So they should be changed as a pair, with LC_CTYPE set first.
[1]: https://docs.microsoft.com/en-us/cpp/c-runtime-library/reference/localeconv?view=vs-2019 |
|