Marc-Andre Lemburg added the comment:
On 08.03.2017 08:20, Serhiy Storchaka wrote:
>
> Serhiy Storchaka added the comment:
>
> Not all platforms use glibc 2.24 as libc.
True. Many don't even use glibc.
> Ideally most of entries should even not exist. We should ask libc for the
> default encoding if it is not included in the locale name. The aliases table
> should be used only for mapping commonly used but unsupported by libc locales
> to supported by libc locales.
I think you have a wrong understanding of what this alias table
is used for: we need it to determine the lib C compatible locale
name without using lib C APIs such as setlocale(), since these are
not thread safe and have side-effects for the whole process.
The alias table is there to avoid having to go to the lib C
to ask it indirectly for more details. Unfortunately, there are
no cross-platform lib C APIs which would allow querying these
details without also changing the local settings of the process.
I know that Python still plays the usual "save current locale,
run setlocale(), revert to previous locale" trick in a couple
of places and this works if Python is the only thread running,
but it doesn't when embedded into other applications.
Regarding the patch: we cannot simply use the output from the
script to set new values. The changes have to be manually
reviewed as well.
E.g. this entry in the table is clearly a typo:
'en_zw.utf8': 'en_ZS.UTF-8',
(it should read en_ZW.UTF-8)
This entry appears wrong as well:
'eo': 'eo_XX.ISO8859-3',
(XX is not a valid country ISO code)
How should we go about this ? Mark all the problems in the PR ?
----------
_______________________________________
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue20087>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
