Tim Lyons <guy.lin...@gmail.com> added the comment:

Surely the user of getlocale as the right to expect that the same thing (i.e. 
ISO language codes) would be returned on all platforms. I am looking at some 
code that provides special purpose date handling routines. The appropriate 
routine is selected by a language code (for the locale category LC_TIME as it 
happens) like fr_FR. In order  to get this to work on different platforms, you 
have to test whether it is windows, and if so use getdefaultlocale, while for 
other platforms, you use getlocale in order to return similar language codes. 
This code would actually be wrong if the application were to change the locale 
inside the application, because on other platforms the change would have an 
effect, while on windows, it would be ignored! [I am running on Mac OS X as it 
happens, not Linux or Windows].
 
So, don’t say that getdefaultloale is not useful, it is the one that is needed 
on Windows!
 
Note this is not a problem with the encoding – some of the discussion and many 
of the related bugs are concerned with the encoding.
 
Also note Marc-Andre pointing out in 
http://mail.python.org/pipermail/python-bugs-list/2004-December/026667.html 
that “getdefaultlocale() mimics the lookup mechanism of setlocale(LC_ALL, "")”. 
I recognise that he is talking about the lookup mechanism rather than the 
results, but it seems to suggest that the results might be similar (if you do 
the same lookup you would get the same result). But “getdefaultlocale returns 
something that setlocale cannot consume on Windows”!

I recognise that it would be difficult to decide to code locale on python so 
that windows returns something that is not the same as the native call, but it 
does seem to me that python locale should translate the Windows language codes 
so that they are the same as are returned on all the other platforms (i.e. ISO 
codes etc).

----------
nosy: +guy.linton

_______________________________________
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue10466>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

Reply via email to