This would have been my suggestion - this is a tough issue - do you have an 
expected behavior you'd like to see?  I can imagine a few:
        1. IronPython supports both byte-array strings and normal strings, and 
therefore "it just works"
        2. IronPython never uses the current locale for string operations, 
effectively breaking Unicode
        3. IronPython does a conversion into ASCII before doing attribute 
access, and somehow converts the upper case turkish I into an ASCII turkish I.

Those 3 options are problematic at best.  An easier solution would be what Curt 
suggested (I'm assuming you're redistributing the standard library yourself).  
I was also thinking that there should be a preexisting way to do this in Python 
but I don't see an upper function that lets you specify the locale or force it 
to do so against an invariance culture.  Maybe just a call to string.translate 
instead?


From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Curt Hagenlocher
Sent: Wednesday, October 31, 2007 11:15 AM
To: Discussion of IronPython
Subject: Re: [IronPython] Import decimal failure with Turkish Locale (IP 1.1)

On 10/31/07, Michael Foord <[EMAIL PROTECTED]> wrote:

The issue is because one of the method names is '_round_ceiling'. In the
Turkish locale, the uppercase version of this is "ROUND_CEİLİNG" (in
Turkish uppercase of "i" is "I" with a dot on top of it). Obviously the
lookup of the corresponding global fails.

In CPython the name is a byte-string, and so '.upper' just uses the
ascii uppercase rather than the locale sensitive version - so we see
failing to import 'decimal.py' as an IronPython bug. As this badly
impacts Resolver we would *love* to see this fixed soon...

Why not change decimal.py to use ToUpperInvariant()?  Are you sharing the file 
with CPython?

--
Curt Hagenlocher
[EMAIL PROTECTED]
_______________________________________________
Users mailing list
Users@lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com

Reply via email to