[Python-Dev] various unix platform build/test issues

[Tim Peters]

[M.-A. Lemburg]
> I'd even coerce strings to floats if possible ;-)
>
> BTW, I implemented that in mxNumber for the fun of it:
>  >>> from mx.Number import *
>  >>> Float(1.23) + '3.45'
> 4.67999999999999998223e+0
>  >>> Rational(2,3) + '3/4'
> 17/12

FixedPoint does a similar thing, coercing strings to FixedPoints by magic.
The lack of a native literal notation for FixedPoints (and rationals) makes
that more attractive than it should be <wink>.

> Seriously, the above was only meant as hint to not rely on
> nb_negative for PyNumber_Check(), but to use nb_int
> for this. After all, code using PyNumber_Check() will expect that
> at least PyNumber_Int() to work on the object. If you check
> for nb_negative, this will not always work, since then complex objects
> would get accepted.

Reality check:  PyNumber_Check() checks for nb_int or nb_float now, and
complex numbers have both slots, but both raise TypeError unconditionally.
So if you believe that PyNumber_Check()'s caller expects PyNumber_Int() to
work, then PyNumber_Check() is already broken in your view.  My view is that
a complex is a number whether or not it can be coerced to some other type,
but that complex is passing PyNumber_Check() more by accident than by design
now.  nb_negative seems a sharper check to me.