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.