Hello Dino (etc),

Hmm... as usual it is a harder problem than it first seems.

Curt's suggestion is helpful (and will probably get us out of a fix - so 
thanks), but patching the standard library (which we do distribute 
separately) is something we had hoped to avoid. To be honest that code 
in 'decimal.py' seems odd and a weird way of achieving what it does.

However - string literals in code should either be in ascii *or* in a 
declared encoding. Some way out of this situation would be nice... 
(Thinking subclasses of strings...)


Dino Viehland wrote:
> 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
> _______________________________________________
> Users mailing list
> Users@lists.ironpython.com
> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com

Users mailing list

Reply via email to