Bugs item #1163325, was opened at 2005-03-14 17:37
Message generated for change (Comment added) made by rhettinger
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1163325&group_id=5470
Category: Python Library
Group: Python 2.4
Status: Open
>Resolution: Fixed
Priority: 5
Submitted By: Marien Zwart (marienz)
>Assigned to: Anthony Baxter (anthonybaxter)
Summary: "special" decimals aren't hashable
Initial Comment:
Python 2.4 (#1, Feb 22 2005, 15:02:34)
[GCC 3.4.3-20050110 (Gentoo Linux 3.4.3.20050110,
ssp-3.4.3.20050110-0, pie-8.7 on linux2
Type "help", "copyright", "credits" or "license" for
more information.
>>> import decimal
>>> hash(decimal.NaN)
Traceback (most recent call last):
File "<stdin>", line 1, in ?
File "/usr/lib/python2.4/decimal.py", line 720, in
__hash__
i = int(self)
File "/usr/lib/python2.4/decimal.py", line 1410, in
__int__
return context._raise_error(InvalidContext)
File "/usr/lib/python2.4/decimal.py", line 2215, in
_raise_error
raise error, explanation
decimal.InvalidOperation
This behaviour doesn't match the comment in
decimal.py's __hash__:
# Decimal integers must hash the same as the ints
# Non-integer decimals are normalized and hashed as strings
# Normalization assures that hast(100E-1) == hash(10)
Would it make sense to wrap the int(self) in an except
block and return hash(str(self.normalize())) if this
raises?
----------------------------------------------------------------------
>Comment By: Raymond Hettinger (rhettinger)
Date: 2005-03-15 00:00
Message:
Logged In: YES
user_id=80475
Fixed. See Lib/decimal.py 1.35.
Anthony, can this be backported to 2.4.1 or does it need to
wait for 2.4.2?
----------------------------------------------------------------------
Comment By: James Y Knight (foom)
Date: 2005-03-14 23:15
Message:
Logged In: YES
user_id=1104715
NaN, Inf, and negInf all fail to hash.
Inf and negInf are equal to themselves, so they don't have any problem
being used as a dict key.
As for NaN, I don't see any harm in allowing it to return a hashcode
anyways, but perhaps you're right.
However, in that case, it would be nice to have the exception raised be
somewhat more regular and expected-looking than a InvalidOperation
from int(). Perhaps it should raise TypeError('Decimal("NaN") is
unhashable').
----------------------------------------------------------------------
Comment By: Tim Peters (tim_one)
Date: 2005-03-14 19:04
Message:
Logged In: YES
user_id=31435
Well, I'm not really a fan of Python's tying hashability
to "usable as a dict key", but given that's what Python
_does_, ya, hashing a NaN doesn't make sense.
marienz, by "special" decimals did you mean only NaNs, or
do you have other cases in mind too?
----------------------------------------------------------------------
Comment By: Raymond Hettinger (rhettinger)
Date: 2005-03-14 17:42
Message:
Logged In: YES
user_id=80475
Since two NaNs are never equal to one another, I would think
that it doesn't make sense to hash them. Tim, do you have
another thoughts on the subject?
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1163325&group_id=5470
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
