weird float() behavior

[pball]

Hi,

so I had a confusion with int() (why an exception for int('3.1416')?
why not just return 3? ok, I read threads from many years ago) and
float(). I've been sifting through the c.l.py archives, but this seems
new.  Basically, int(float(someString)) seems always to return zero
with a particular mix of gcc and python versions.

(note carefully the machine name, gcc & python versions)

[pball at wylbur]% python
Python 2.2.2 (#1, Mar 29 2003, 23:20:21)
[GCC 3.2.2 20030322 (Gentoo Linux 1.4 3.2.2-r2)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> s = '16073.0'
>>> int( float(s) ) 0
>>>

hello! int(i)==0?? that's not right. I went to another machine.

[pball at silas]% python
Python 2.2.1 (#1, Aug 30 2002, 12:15:30)
[GCC 3.2 20020822 (Red Hat Linux Rawhide 3.2-4)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> s = '16073.0'
>>> int(float(s)) 16073
>>>

This is more what I'd expect. So a bit more:

[pball at piglet]% python
Python 2.2.2 (#1, Mar 20 2003, 02:05:28)
[GCC 3.2.2] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> s = '16073.0'
>>> int(float(s)) 16073
>>>

Again, what I'd expect. To be complete: 

pball at mina> python
Python 1.5.2 (#1, Apr  3 2002, 18:16:26)  [GCC 2.96 20000731 (Red Hat
Linux 7.2 2 on linux-i386
Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam
>>> s = '16073.0'
>>> int( float(s) ) 16073
>>>

ok, it seems pretty likely that it's the gentoo python 2.2.2 with the
bleeding-edge gcc 3.2.2. I found that float was triggering it, but
actually, int() is just very sick:


[pball at wylbur]% python                                                
 ~
Python 2.2.2 (#1, Mar 29 2003, 23:20:21)
[GCC 3.2.2 20030322 (Gentoo Linux 1.4 3.2.2-r2)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> s = '3.1415' 
>>> int( float(s) ) -610
>>> int( 3.1416 ) 0
>>> int( 3.1415 ) -610
>>> int( 3.1417 ) 0
>>> int( 3.1419 )
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
OverflowError: float too large to convert
>>>

Ok, that's enough.  Has anyone else seen this?  Any ideas how I broke
it so completely? Is there more info I can post to better identify it?
Is there a regression test we could add to the post-compile process to
flag this?

Thanks - PB.