[issue10356] decimal.py: hash of -1

Raymond Hettinger rhettin...@users.sourceforge.net added the comment: Committed the ValueError in r86517 (py3k) As discussed on IRC, I've reverted this change. -- resolution: fixed - invalid status: open - closed ___ Python tracker

[issue10356] decimal.py: hash of -1

Mark Dickinson dicki...@gmail.com added the comment: Hmm. Does anyone remember the reason for making sNaNs unhashable in the first place. I recall there was a discussion about this, but can't remember which issue. -- ___ Python tracker

[issue10356] decimal.py: hash of -1

Mark Dickinson dicki...@gmail.com added the comment: Ah, now I remember: making sNaNs hashable has the potential to introduce seemingly random exceptions with set and dict operations. The logic went something like: (1) if sNaNs are hashable, you can put them in dicts, (2) operations on

[issue10356] decimal.py: hash of -1

Stefan Krah stefan-use...@bytereef.org added the comment: If I'm not mistaken, signaling NaNs are only created when the user explicitly initializes a variable. I see this as direct request to raise an exception whenever the variable is accessed in a way that changes the outcome of the program:

[issue10356] decimal.py: hash of -1

Mark Dickinson dicki...@gmail.com added the comment: [Stefan] ... a direct request to raise an exception... Understood; the issue is that this conflicts with the general expectation that equality (and inequality) comparisons always work (at least, for objects that are perceived as

[issue10356] decimal.py: hash of -1

Mark Dickinson dicki...@gmail.com added the comment: Grr. Horrible formatting on that last comment. Sorry about that. Anyway, I'd be interested to hear other people's opinions. -- ___ Python tracker rep...@bugs.python.org

[issue10356] decimal.py: hash of -1

Mark Dickinson dicki...@gmail.com added the comment: I wouldn't risk changing the exception type in 2.7. It's fine for 3.2. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10356 ___

[issue10356] decimal.py: hash of -1

Stefan Krah stefan-use...@bytereef.org added the comment: Thanks for all the comments! I agree that a change in 2.7 might cause trouble. Committed the ValueError in r86517 (py3k). -- resolution: - fixed stage: patch review - committed/rejected status: open - closed

[issue10356] decimal.py: hash of -1

Terry J. Reedy tjre...@udel.edu added the comment: Should there be a 'versionchanged' note in the doc, even if the error type was not documented? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10356

[issue10356] decimal.py: hash of -1

Raymond Hettinger rhettin...@users.sourceforge.net added the comment: The choice between ValueError and TypeError can sometimes be ambiguous and seem arbitrary and I understand why you're gravitating towards ValueError (because it works some values and not others), but in this case the API is

[issue10356] decimal.py: hash of -1

Changes by Raymond Hettinger rhettin...@users.sourceforge.net: -- assignee: skrah - rhettinger ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10356 ___

[issue10356] decimal.py: hash of -1

Stefan Krah stefan-use...@bytereef.org added the comment: Raymond Hettinger rep...@bugs.python.org wrote: The choice between ValueError and TypeError can sometimes be ambiguous and seem arbitrary and I understand why you're gravitating towards ValueError (because it works some values and

[issue10356] decimal.py: hash of -1

Stefan Krah stefan-use...@bytereef.org added the comment: Fixed the hash in r86492, excluding the TypeError fix. Should I fix the TypeError in both 2.7 and 3.2? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10356

[issue10356] decimal.py: hash of -1

Terry J. Reedy tjre...@udel.edu added the comment: I presume you mean this: if self._is_special: if self.is_snan(): -raise TypeError('Cannot hash a signaling NaN value.') +raise ValueError('Cannot hash a signaling NaN value.') My

[issue10356] decimal.py: hash of -1

Mark Dickinson dicki...@gmail.com added the comment: Okay; go ahead and apply (preferably in two separate commits, since you're fixing two only marginally related issues here). -- assignee: - skrah ___ Python tracker rep...@bugs.python.org

[issue10356] decimal.py: hash of -1

Mark Dickinson dicki...@gmail.com added the comment: The Fraction type has the same behaviour, so I've fixed it to match the proposed new Decimal behaviour in r86448. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10356

[issue10356] decimal.py: hash of -1

Changes by Terry J. Reedy tjre...@udel.edu: -- nosy: +terry.reedy ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10356 ___ ___ Python-bugs-list

[issue10356] decimal.py: hash of -1

New submission from Stefan Krah stefan-use...@bytereef.org: When the __hash__ method is called directly, the hash of -1 is -1: from decimal import * Decimal(-1).__hash__() -1 hash(Decimal(-1)) -2 I've a patch, which also sneaks in a ValueError. -- components: Library (Lib) files:

[issue10356] decimal.py: hash of -1

Mark Dickinson dicki...@gmail.com added the comment: Are there situations where this is a problem? I don't think that there's any requirement that the __hash__ method for a user-defined Python type not return -1. (It's also allowed to return values outside the range of hash values; these

[issue10356] decimal.py: hash of -1

Amaury Forgeot d'Arc amaur...@gmail.com added the comment: It's not about the hash value, but about consistency: help(Decimal.__hash__) says x.__hash__() == hash(x), but this is not true for x=Decimal(-1). -- nosy: +amaury.forgeotdarc ___ Python

[issue10356] decimal.py: hash of -1

Raymond Hettinger rhettin...@users.sourceforge.net added the comment: Good catch Stefan. This is a regression from Py2.6. The behavior for decimal should match that for int. IDLE 2.6.2 hash(-1) -2 (-1).__hash__() -2 from decimal import * hash(Decimal(-1)) -2 Decimal(-1).__hash__()