proposed language change to int/int==float (was: PEP0238 lament)

[Bengt Richter]

On Fri, 27 Jul 2001 21:43:51 GMT, Guido van Rossum <guido at python.org> wrote:

>bokr at accessone.com (Bengt Richter) writes:
>
>> On Fri, 27 Jul 2001 08:54:13 -0400, Guido van Rossum <guido at zope.com> wrote:
>> [...]
>> >Assuming we'll adopt a variation of Scheme's numerical tower (which
>> >I'm currently in favor of, more or less), this won't happen.  Floats
>> >and complex would always be considered inexact (and ints and rationals
>> >exact), and inexact numbers are not allowed as sequence indices, even
>> >if their exact value is an integer.
>> >
>> Why would complex have to be inexact if both its
>> real and imaginary parts were exact?
>> 
>> This looks exact, but will it be?
>>  >>> (1+2j)**2
>>  (-3+4j)
>
>Probably not -- I don't think it's worth to have a separate exact and
>inexact complex numbers, especially since exact numbers will probably
>be represented as rationals (with ints and long ints as a special-case
>optimization), while inexact numbers will probably all use some form
>of floating point (binary or decimal).
>
I'm not sure I follow what yoou mean by separate exact and inexact
complex numbers. Why would
    isexact(cn)
not amount to
    isexact(cn.real) and isexact(cn.imag) ?
And then just do the math operations as needed on cn.real and cn.imag and
let their idividual exactness chips fall where they may?

Does the complex implementation need to know how .real and .imag are stored?
I imagine if you hand built a class implementation, you would have separate
unified numbers (obviously excluding complex ;-) for real and imag.

How much different is  the builtin complex from a class implementation?
Is it an optimization issue?