A RetroSearch Logo

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Search Query:

Showing content from https://mail.python.org/pipermail/python-dev/2010-March/098842.html below:

[Python-Dev] Mixing float and Decimal -- thread reboot

[Python-Dev] Mixing float and Decimal -- thread rebootMark Dickinson dickinsm at gmail.com
Wed Mar 24 22:09:26 CET 2010
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
More information about the Python-Dev mailing list

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