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
