[Python-Dev] various unix platform build/test issues
M.-A. Lemburg
mal@lemburg.com
Thu, 20 Feb 2003 18:59:26 +0100
Tim Peters wrote:
> [M.-A. Lemburg]
>
>>Isn't that caveat in the complex implementation ? Converting a
>>complex with 0 img part would not cause any loss of information
>>(apart from the usual integer truncations ;-)
>
> Hmm. Have you ever met a coercion you didn't like <0.9 wink>?
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
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.
> float(complex) also raises an exception unconditionally, and I think for
> good reasons -- what someone *intends* by trying to convert a complex number
> to a float or an int is a mystery. The exceptions raised suggest one
> plausible intent and how to get at it clearly:
>
>>>>float(1+0j)
>
> Traceback (most recent call last):
> File "<stdin>", line 1, in ?
> TypeError: can't convert complex to float; use e.g. abs(z)
I know :-)
--
Marc-Andre Lemburg
eGenix.com
Professional Python Software directly from the Source (#1, Feb 20 2003)
>>> Python/Zope Products & Consulting ... http://www.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
Python UK 2003, Oxford: 40 days left
EuroPython 2003, Charleroi, Belgium: 124 days left