Martin v. Löwis <mar...@v.loewis.de> added the comment: >> That would be highly non-portable, and repeat the mistakes of >> getdefaultlocale. > > You say that often, but I don't really know why. It's certainly portable > between various Unix platforms, perhaps not Windows, but then i18n > on Windows is a different story altogether.
No, it's absolutely not portable across Unix platforms. Looking at LANG or LC_ALL does *not* allow you to infer the region name, or the locale's character set. For example, using glibc, in some installations, /etc/locale.alias is considered to map a value of LANG to the final locale name. As an option, glibc also considers a LOCALE_ALIAS_PATH that may point to a (colon-separated) path of files to search for locale aliases. Other systems may use other databases to map a locale name to locale properties. Unless you know exactly what version of C library is running on a system, parsing environment variables yourself is doomed to fail. ---------- title: 3.x locale does not default to C, contrary to the documentation and to 2.x behavior -> 3.x locale does not default to C, contrary to the documentation and to 2.x behavior _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue6203> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
