eryksun added the comment:
For 3.5 this affects Windows as well, since the new CRT supports RFC1766
language codes, but only without a codepage spec:
Python 3.5.0a1 (v3.5.0a1:5d4b6a57d5fd, Feb 7 2015, 18:15:14)
[MSC v.1900 64 bit (AMD64)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import locale
>>> locale.setlocale(locale.LC_ALL, 'en-GB')
'en-GB'
>>> locale.getlocale()
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "C:\Program Files\Python35\lib\locale.py", line 578, in getlocale
return _parse_localename(localename)
File "C:\Program Files\Python35\lib\locale.py", line 487, in
_parse_localename
raise ValueError('unknown locale: %s' % localename)
ValueError: unknown locale: en-GB
On Vista+ (since 3.5 drops XP support) the codepage can be queried easily via
GetLocaleInfoEx:
>>> from ctypes import *
>>> LOCALE_IDEFAULTANSICODEPAGE = 0x1004
>>> GetLocaleInfoEx = WinDLL('kernel32').GetLocaleInfoEx
>>> info = (c_wchar * 100)()
>>> GetLocaleInfoEx("en-GB", LOCALE_IDEFAULTANSICODEPAGE, info, len(info))
5
>>> info.value
'1252'
>>> GetLocaleInfoEx("zh-CN", LOCALE_IDEFAULTANSICODEPAGE, info, len(info))
4
>>> info.value
'936'
Note that Windows follows the RFC spec here (not POSIX), using a hyphen instead
of an underscore.
This is a bit of tangent, but for the Windows full language_country.codepage
form, the X-11 based locale_alias dict is generally useless. So, contrary to
the docs, on Windows getlocale doesn't return the language code in RFC 1766
form. In some cases it does, but only by chance.
----------
components: +Windows
nosy: +eryksun, steve.dower, tim.golden, zach.ware
_______________________________________
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue20088>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
