Martin v. Löwis <mar...@v.loewis.de> added the comment: > getdefaultlocale() provides a way to access the default locale > (and encoding) on a platform without requiring a call to > setlocale(LC_ALL, "")
That's what it's meant to do, but this is not what it actually does. In fact, there is no way of determining the locale's encoding without the help o fthe C library. As for "default locale": this is a flawed notion in itself. If I use one locale for messages, and the other for date representation - which one should be the "default" locale? Also, "default" in what respect? > getpreferredencoding() just provides encoding information. It doesn't > provide locale information, so I don't see how that could be used > as replacement for getdefaultlocale(). Many applications use getdefaultlocale()[1], i.e. ignore the locale part of the result. They can easily be rewritten to use getpreferredencoding. > The table needed for normalizing the various locale strings used in > the LANG environment variable (and others) needs to be updated every > now and then, but that's natural for a resource that changes based > on what people use locales for in real life. However, it also changes based on local administrator preferences - something that the implementation does not take into account at all. It may also depend on OS vendor preferences, which is also not considered in the implementation. IOW, it returns bogus results. ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue8374> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
