Author fomcl@yahoo.com
Recipients fomcl@yahoo.com, r.david.murray
Date 2015-02-13.19:48:27
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1423856907.39.0.333138163785.issue23425@psf.upfronthosting.co.za>
In-reply-to
Content
I agree that the two issues are related, but I don't see how they could be duplicates. But maybe that's because I do not know the underlying code.

issue 10466 is mostly about getdefaultlocale() and whether it's desirable or not that its return value is always uniq-esque, including on windows. The failed call to locale.py*) as a script would demonstrate that the getdefaultlocale() return value ought to be platform-specific and ready for consumption by setlocale(). That's how I read that issue. I personally find it useful to have getdefaultlocale() --a nice, harmonized locale string.

With getlocale in Windows, however, the return value is sometimes unix-like, sometimes windows-specific. Until a couple of days ago I thought getlocale was entirely platform-specific. Why should locale.setlocale(locale.LC_ALL, ".".join(locale.getlocale())) succeed on my Dutch windows system, but fail on my neighbour's German windows system?

In my humble opinion:
-setlocale should return nothing. It's a setter
-getlocale should return a platform-specific locale specification, probably what is currently returned by setlocale. The output should be ready for consumption by setlocale.
-getdefaultlocale should ALWAYS return a harmonized/unix-like locale specification. In Unix, but not in Windows, it could be used as an argument for setlocale.

My two cents.

Best wishes,
Albert-Jan

*) which also fails on Python 2.7 and 3.4 on my Dutch Windows 7 64, btw.
History
Date User Action Args
2015-02-13 19:48:27fomcl@yahoo.comsetrecipients: + fomcl@yahoo.com, r.david.murray
2015-02-13 19:48:27fomcl@yahoo.comsetmessageid: <1423856907.39.0.333138163785.issue23425@psf.upfronthosting.co.za>
2015-02-13 19:48:27fomcl@yahoo.comlinkissue23425 messages
2015-02-13 19:48:27fomcl@yahoo.comcreate