[issue10356] decimal.py: hash of -1

Raymond Hettinger 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 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 ___

[issue10356] decimal.py: hash of -1

Mark Dickinson 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 immutable). I think there

[issue10356] decimal.py: hash of -1

Stefan Krah 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: This is the example I gave:

[issue10356] decimal.py: hash of -1

Mark Dickinson 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 dicts make equality

[issue10356] decimal.py: hash of -1

Mark Dickinson 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

Stefan Krah added the comment: Raymond Hettinger 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 not others), but in this case the API is > alre

[issue10356] decimal.py: hash of -1

Changes by Raymond Hettinger : -- assignee: skrah -> rhettinger ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue10356] decimal.py: hash of -1

Raymond Hettinger 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 already fixed by what hash() doe

[issue10356] decimal.py: hash of -1

Terry J. Reedy added the comment: Should there be a 'versionchanged' note in the doc, even if the error type was not documented? -- ___ Python tracker ___ _

[issue10356] decimal.py: hash of -1

Stefan Krah 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 ___ P

[issue10356] decimal.py: hash of -1

Mark Dickinson added the comment: I wouldn't risk changing the exception type in 2.7. It's fine for 3.2. -- ___ Python tracker ___ _

[issue10356] decimal.py: hash of -1

Terry J. Reedy 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 understanding is that while

[issue10356] decimal.py: hash of -1

Stefan Krah 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 ___ ___

[issue10356] decimal.py: hash of -1

Mark Dickinson 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 ___ __

[issue10356] decimal.py: hash of -1

Mark Dickinson 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

[issue10356] decimal.py: hash of -1

Changes by Terry J. Reedy : -- nosy: +terry.reedy ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.p

[issue10356] decimal.py: hash of -1

Raymond Hettinger 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__() -2 -- no

[issue10356] decimal.py: hash of -1

Amaury Forgeot d'Arc 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 tracker

[issue10356] decimal.py: hash of -1

Mark Dickinson 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 get automatically reh

[issue10356] decimal.py: hash of -1

New submission from Stefan Krah : 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: decimal_hash.patch