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
