Mark Dickinson <dicki...@gmail.com> added the comment:
> Like you mentioned before a lot of care is taken in 'floatobject.c' to >
> ensure that the comparison is robust. Would it be a good approach to
> leverage that work?
Absolutely, yes! I was thinking of moving that chunk of code out of
float_richcompare and into something like _PyLong_CompareWithDouble (in
Objects/longobject.c). Then it can be used by both float_richcompare and
complex_richcompare.
Hmm. This works well for py3k, but not so well for trunk, where we have to
deal with plain 'int's as well.
I'd definitely like this fixed in 2.7 and 3.2: it's horrible behaviour. I'm
still wondering about 2.6 and 3.1. I just discovered that there's actually a
test for part of this behaviour (first line of test_richcompare in
test_complex.py):
self.assertRaises(OverflowError, complex.__eq__, 1+1j, 1<<10000)
Nevertheless, I still maintain that this is wrong: raising an exception in
__eq__ is always a dangerous thing to do for hashable objects, since it leads
to confusing behavour like this:
Python 2.5.1 (r251:54863, Dec 6 2008, 10:49:39)
[GCC 4.2.1 (SUSE Linux)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> s = set([2**1024])
>>> s.add(complex(0))
>>> s.add(complex(2))
>>> s.add(complex(1))
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
OverflowError: long int too large to convert to float
----------
_______________________________________
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue8748>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
