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
History
Date User Action Args
2020-02-11 19:36:49eryksunsetrecipients: + eryksun, terry.reedy, paul.moore, vstinner, tim.golden, zach.ware, steve.dower
2020-02-11 19:36:49eryksunsetmessageid: <1581449809.49.0.567352273734.issue38324@roundup.psfhosted.org>
2020-02-11 19:36:49eryksunlinkissue38324 messages
2020-02-11 19:36:49eryksuncreate