Sebastian Berg added the comment:
This is closed, and maybe I am missing something. But from a general point of
view, why does hashing of NaN not raise an error as it did for decimals, i.e.
why was this not resolved exactly the other way around? I am mostly just
wondering about this it is not
Mark Dickinson added the comment:
Sebastian: I think this discussion is a bit off-topic for this particular bug;
you might want to raise it on python-dev or python-ideas instead.
Bear in mind, though, that the behaviour of NaNs and containers has been
discussed to death many times in the
Sebastian Berg added the comment:
Thanks, yes, you are right, should have googled a bit more anyway. Though I did
not find much on the hashable vs unhashable itself, so if I ever stumble across
it again, I will write a mail...
--
___
Python tracker
Mark Dickinson dicki...@gmail.com added the comment:
r79588 and r79589 were merged to py3k in r79668.
--
resolution: invalid - fixed
stage: - committed/rejected
status: open - closed
___
Python tracker rep...@bugs.python.org
Mark Dickinson dicki...@gmail.com added the comment:
Thanks, Stefan. Applied to trunk in r79588. Still needs to be forward ported
to py3k.
--
versions: +Python 3.2
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue7279
Mark Dickinson dicki...@gmail.com added the comment:
Allowed hashing of Decimal('nan') in r79589; Decimal('snan') continues to
raise TypeError.
I've also rewritten Decimal.__hash__ a little bit, so that it won't care if
float('inf') raises an exception. This will all be much neater if the
Stefan Krah stefan-use...@bytereef.org added the comment:
Mark, this looks great, thanks.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue7279
___
Mark Dickinson dicki...@gmail.com added the comment:
Re-opening to address a couple of points that came out of the python-dev
discussion:
(1) As Stefan pointed out on python-dev, equality and inequality comparisons
involving signaling nans should signal (order comparisons already do). IEEE
Mark Dickinson dicki...@gmail.com added the comment:
I think hash(Decimal(snan)) should also succeed
On second thoughts, this would be bad, since it would lead to unpredictable
results for sets of dicts containing a signaling nan:
from decimal import Decimal
[69536 refs]
s =
Mark Dickinson dicki...@gmail.com added the comment:
Here's a patch (against py3k) to make all comparisons involving signaling nans
raise InvalidOperation.
Stefan, does this look okay to you?
--
keywords: +patch
Added file: http://bugs.python.org/file16631/issue7279.patch
Mark Dickinson dicki...@gmail.com added the comment:
There's a second issue to consider here, which is that Python uses
equality as specified by the == operator as the basic equivalence relation
for set and dict membership tests. So as a general rule, an equality test
between two objects of
New submission from Stefan Krah stefan-use...@bytereef.org:
I'm not sure this is a bug, but I am trying to understand the rationale
for mimicking IEEE 754 for == and != comparisons involving NaNs. The
comment in decimal.py says:
Note: The Decimal standard doesn't cover rich comparisons for
Changes by Stefan Krah stefan-use...@bytereef.org:
--
type: - behavior
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue7279
___
___
13 matches
Mail list logo
