ISTM the same reasoning applies equally to complex numbers. My interestCPython 2.4, 2.5, and 3.0 on WinXP (and hence I presume 2.6) produce
arose because of what I think is a bug in pypy's complex printing:
Python 2.4.1 (pypy 1.0.0 build 56124) on linux2
Type "help", "copyright", "credits" or "license" for more information.
``RPython: we use it so you don't have to''(240733537691613523198532543387690598400L+23649556 5429619338248192Lj)>>>(1.1+1.1j)**200
This strangeness comes about because a hack used to recover cpython's
behaviour fails at large values. (x.real == floor(x.real), so it
decides the value's an integer, and returns the repr of int(x.real).)
It's trivial to fix but I think cpython's behaviour is slightly odd
here, and the real and imaginary parts of the complex repr should be
identical to those of the underlying floats.
(with a trivial variation)
(2.407335376916204e+38+2.3649556542962612e+23j)>>(1.1+1.1j)**200
That Pypy disagrees in the 14th digit is a bit odd, but I suspect a C
math library difference. Unless they are actually calculating 40 digits
exactly, the extra digits should be filled with 0s if they want
integers. Take that, and whatever you think is strange, up with them.