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