[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.
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4