On Wed, Mar 24, 2010 at 2:09 PM, Mark Dickinson <dicki...@gmail.com> wrote: > 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?
I'd call it a bug. _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
