On Solaris 8, running Python 2.2.2, the built-in 
function long() gave me the following peculiar results
when applied to a floating-point argument.

(Unfortunately I don't have administrative access to
this machine, so couldn't test to see whether Python
2.3a has the same problems.)

s0100% uname -a
SunOS s0100.math.lsa.umich.edu 5.8 Generic_108528-14
sun4u sparc SUNW,Sun-Blade-1000
s0100% python
Python 2.2.2 (#22, Dec 23 2002, 12:02:55) 
[GCC 3.0.3] on sunos5
Type "help", "copyright", "credits" or "license" for
more information.
>>> long(3.1415)
0L
>>> _ == 0L
0
>>> long(6e20)
00000000000000000L
>>> _ - 1
37778931862957161709567L
>>> int(3.1415)
3

Logged In: YES 
user_id=595280

My machine has similar configuration, but works fine;

$ uname -a
SunOS abbey 5.8 Generic_108528-18 sun4u sparc
SUNW,Sun-Blade-1000

$ python22
Python 2.2.2 (#1, Oct 15 2002, 14:20:16)
[GCC 2.95.3 20010315 (release)] on sunos5
>>> long(3.1415)
3L
>>> long(6e20)
600000000000000000000L
>>> _ - 1
599999999999999999999L

I think it's gcc/glibc optimization issue.

Logged In: YES 
user_id=33168

Mark, can you verify if this is a compiler problem?  I also
don't have this problem on a sun?

Logged In: YES 
user_id=703403

The sysadmin here is (very helpfully) looking into this; 
I'll report any findings.

I should probably also have pointed out in my original
report that this is a 64-bit compile of Python.  (Apologies
if this is obvious to everyone;  it wasn't to me.)

Logged In: YES 
user_id=31435

Python runs on many 64-bit platforms (starting in 1993), so 
that's not likely a real problem.  A compiler optimization bug 
is much more likely, or perhaps a config problem when 
compiling Python.

Logged In: YES 
user_id=703403

This does indeed seem to be a compiler optimization bug;  
after removing all occurrences of `-O3' from the configure 
script and rebuilding, the problem disappeared.  I guess that 
it's probably not worth trying to track this problem to its source 
unless it persists with newer versions of gcc.