[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