This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author ixokai
Recipients ixokai, ronaldoussoren
Date 2010-10-20.15:31:22
SpamBayes Score 6.27276e-15
Marked as misclassified No
Message-id <1287588685.92.0.0691926945263.issue10154@psf.upfronthosting.co.za>
In-reply-to
Content
In the course of investigating issue10092, Georg discovered that the behavior of locale.normalize() on Mac is bad.

Basically, "en_US.UTF-8" is how the "correct" locale string should be spelled on the Mac. If you drop the dash, it fails: which locale.normalize does, so you can't pass the return value of the function to setlocale, even though that's what its documented to be for.

If that isn't clear, this should demonstrate (from /branches/py3k):


Top-2:build pythonbuildbot$ ./python.exe
Python 3.2a3+ (py3k:85631, Oct 17 2010, 06:45:22) 
[GCC 4.2.1 (Apple Inc. build 5664)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import locale
[51767 refs]
>>> locale.normalize("en_US.UTF-8")
'en_US.UTF8'
[51770 refs]
>>> locale.setlocale(locale.LC_TIME, 'en_US.UTF8')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/Users/pythonbuildbot/test/build/Lib/locale.py", line 538, in setlocale
    return _setlocale(category, locale)
locale.Error: unsupported locale setting
[51816 refs]
>>> locale.setlocale(locale.LC_TIME, 'en_US.UTF-8')
'en_US.UTF-8'
[51816 refs]

The precise same behavior exists on my stock/system Python 2.6, too, fwiw. (Not that it can be fixed on 2.6, but maybe 2.7?)
History
Date User Action Args
2010-10-20 15:31:26ixokaisetrecipients: + ixokai, ronaldoussoren
2010-10-20 15:31:25ixokaisetmessageid: <1287588685.92.0.0691926945263.issue10154@psf.upfronthosting.co.za>
2010-10-20 15:31:23ixokailinkissue10154 messages
2010-10-20 15:31:22ixokaicreate