Author eryksun
Recipients eryksun, paul.moore, steve.dower, terry.reedy, tim.golden, vstinner, zach.ware
Date 2019-10-05.18:28:18
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1570300098.52.0.314074342888.issue38324@roundup.psfhosted.org>
In-reply-to
Content
Terry, the test_winconsoleio problem is issue 38325. Test cases with surrogate pairs that are known to fail in recent builds of Windows 10 have to be split out.

For the "ps_AF" locale failure that you noted, in my case with Windows 10 18362, I have to first modify the tests in Lib/test/test__locale.py to set LC_CTYPE before setting LC_NUMERIC. Otherwise the lconv result in C has the wrong encoding, and PyUnicode_DecodeLocale fails. 

After making this change, I can reproduce the noted failure. The "ps_AF" (Pashto, Afghanistan) case will have to be skipped in Windows because the system NLS data does not agree with the assumed Arabic decimal and thousands separator, U+066B and U+066C, but instead uses "," and ".". This can be verified directly via WINAPI GetLocaleInfoEx:

    >>> n = kernel32.GetLocaleInfoEx('ps-AF', LOCALE_SSCRIPTS, buf, len(buf))
    >>> buf.value
    'Arab;'
    >>> n = kernel32.GetLocaleInfoEx('ps-AF', LOCALE_SDECIMAL, buf, len(buf))
    >>> buf.value
    ','
    >>> n = kernel32.GetLocaleInfoEx('ps-AF', LOCALE_STHOUSAND, buf, len(buf))
    >>> buf.value
    '.'

In case this was a quirk in the NLS data for languages that use a Perso-Arabic script, such as Pashto, I also checked Saudi Arabia ("ar-SA"), which uses a standard Arabic script, but the result was the same.
History
Date User Action Args
2019-10-05 18:28:18eryksunsetrecipients: + eryksun, terry.reedy, paul.moore, vstinner, tim.golden, zach.ware, steve.dower
2019-10-05 18:28:18eryksunsetmessageid: <1570300098.52.0.314074342888.issue38324@roundup.psfhosted.org>
2019-10-05 18:28:18eryksunlinkissue38324 messages
2019-10-05 18:28:18eryksuncreate