On Thu, Mar 25, 2010 at 1:15 AM, Jeffrey Yasskin <jyass...@gmail.com> wrote: > 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. >
Thanks, Jeffrey (and everyone else who answered). Fixed in r79456 (py3k) and r79455 (trunk). Mark _______________________________________________ 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
