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
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