Slight change of topic. I've been implementing the extra comparisons required for the Decimal type and found an anomaly while testing. Currently in py3k, order comparisons (but not ==, !=) between a complex number and another complex, float or int raise TypeError: >>> z = complex(0, 0) >>> z < int() Traceback (most recent call last): File "<stdin>", line 1, in <module> TypeError: unorderable types: complex() < int() >>> z < float() Traceback (most recent call last): File "<stdin>", line 1, in <module> TypeError: unorderable types: complex() < float() >>> z < complex() Traceback (most recent call last): File "<stdin>", line 1, in <module> TypeError: unorderable types: complex() < complex() But Fraction is the odd man out: a comparison between a Fraction and a complex raises a TypeError for complex numbers with nonzero imaginary component, but returns a boolean value if the complex number has zero imaginary component: >>> z < Fraction() False >>> complex(0, 1) < Fraction() Traceback (most recent call last): File "<stdin>", line 1, in <module> TypeError: unorderable types: complex() < Fraction() I'm tempted to call this Fraction behaviour a bug, but maybe it arises from the numeric integration themes of PEP 3141. Any ideas? Mark
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