homepage

According to reports on comp.lang.python, the current 
SVN trunk fails to handle floating point literals if 
the locale is changed:
>>> import locale 
>>> locale.setlocale(locale.LC_ALL, '') 
'German_Germany.1252' 
>>> 3.141592 
3.0 
This works just fine in 2.4.2.
See the later portions of the thread "build 
curiosities of svn head (on WinXP)" for more details:
http://groups.google.com/group/comp.lang.python/browse_
frm/thread/226584dd47047bb6/e609cb1a0d47e98f

Logged In: YES 
user_id=38376
I just confirmed this on Unix:
$ export LANG=sv_SE.utf8
$ ./python
Python 2.5a0 (41806M, Dec 25 2005, 12:12:29)
[GCC 2.96 20000731 (Red Hat Linux 7.2 2.96-112.7.2)] on 
linux2
Type "help", "copyright", "credits" or "license" for more 
information.
>>> 3.14
3.1400000000000001
>>> import locale
>>> locale.setlocale(locale.LC_ALL, "")
'sv_SE.utf8'
>>> 3.14
3.0
>>>

Logged In: YES 
user_id=55188
This looks like a bug introduced by AST import;
r39757 is okay but r39762 has such an error.

Logged In: YES 
user_id=55188
Okay. Here's a fix.

Logged In: YES 
user_id=33168
Wow, I thought for sure I broke it with my recent patch to remove support for 
hex floats. But it looks like just an AST problem (which I can be blamed for 
too :-). The patch looks fine, but could you add tests so this doesn't happen 
again. Thanks!
I'll be back in a week and try to fix it then if no one gets back to it.

Logged In: YES 
user_id=38376
I'm not sure you can make too many assumptions about
the locale in the test suite, but I'm pretty sure that
it would be a good idea to let your "build robot" run
the test suite twice; once with the standard C locale,
and once with a non-US locale (e.g. sv_SE.utf8 which
does include some odd characters, different date and
money formats, and a decimal comma).

Logged In: YES 
user_id=55188
The new patch tests it along with other locale-dependent 
tests on test__locale. How about this?

Logged In: YES 
user_id=38376
Looks good to me. I'll check this in shortly.

Logged In: YES 
user_id=38376
Verified and fixed in SVN. Assinging to Neal, in case
he wants to add an extra locale test pass to his build
robot.

Logged In: YES 
user_id=357491
This still fails on OS X 10.4.4:
AssertionError: using eval('3.14') failed for eu_ES
This is using rev. 42094.

Logged In: YES 
user_id=1188172
Neal, you checked in a workaround in test__locale for eu_ES.
Can this be closed then?

Logged In: YES 
user_id=33168
Keeping open as a reminder to fix the regression tests
running on the PSF box every 12 hours. Need to have a run
in a different locale.

Logged In: YES 
user_id=1064183
I have tried this under r43476, with ca_ES.UTF-8 locale, and
it seems to work right::
 Python 2.5a0 (trunk:43476, Mar 31 2006, 15:46:07) 
 [GCC 4.0.2 20050808 (prerelease) (Ubuntu 4.0.1-4ubuntu9)]
on linux2
 Type "help", "copyright", "credits" or "license" for more
information.
 >>> import locale
 >>> 3.141592
 3.1415920000000002
 >>> locale.setlocale(locale.LC_ALL, '')
 'ca_ES.UTF-8'
 >>> 3.141592
 3.1415920000000002
 >>> 

Do we have a test for the problem which verifies the behavior or can I
close the bug?

It seems it has been fixed.