One option might be a non-technical solution: Instead of you redistributing the 
library (or modified library) we distribute it w/ IronPython - and then you're 
just including the combined package.  There's other reasons why it'd be good 
for us to do this (help, encodings, warnings, etc...).  Unfortunately there's 
some internal process required before we cross that hurdle that we've simply 
been putting off.

I'm kicking off the discussions that are necessary to see if we can get this 
going.  It might take a couple of weeks (or who knows, maybe longer) so a 
little patience might be required.  Anyway, let me know what you think of that 
solution.

-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Michael Foord
Sent: Wednesday, October 31, 2007 5:26 PM
To: Discussion of IronPython
Subject: Re: [IronPython] [python] Re: Import decimal failure with Turkish 
Locale (IP 1.1)

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

Michael
http://www.manning.com/foord

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
> [EMAIL PROTECTED]
> _______________________________________________
> Users mailing list
> Users@lists.ironpython.com
> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>
>

_______________________________________________
Users mailing list
Users@lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
_______________________________________________
Users mailing list
Users@lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com

Reply via email to