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).