[Python-Dev] PyObject_RichCompareBool identity shortcut (original) (raw)
Nick Coghlan ncoghlan at gmail.com
Thu Apr 28 08:54:08 CEST 2011
- Previous message: [Python-Dev] PyObject_RichCompareBool identity shortcut
- Next message: [Python-Dev] PyObject_RichCompareBool identity shortcut
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
On Thu, Apr 28, 2011 at 4:20 PM, Glenn Linderman <v+python at g.nevcal.com> wrote:
In that bug, Nick, you mention that reflexive equality is something that container classes rely on in their implementation. Such reliance seems to me to be a bug, or an inappropriate optimization, rather than a necessity. I realize that classes that do not define equality use identity as their default equality operator, and that is acceptable for items that do not or cannot have any better equality operator. It does lead to the situation where two objects that are bit-for-bit clones get separate entries in a set... exactly the same as how NaNs of different identity work... the situation with a NaN of the same identity not being added to the set multiple times seems to simply be a bug because of conflating identity and equality, and should not be relied on in container implementations.
No, as Raymond has articulated a number of times over the years, it's a property of the equivalence relation that is needed in order to present sane invariants to users of the container. I included in the bug report the critical invariants I am currently aware of that should hold, even when the container may hold types with a non-reflexive definition of equality:
assert [x] == [x] # Generalised to all container types assert not [x] != [x] # Generalised to all container types for x in c: assert x in c assert c.count(x) > 0 # If applicable assert 0 <= c.index(x) < len(c) # If applicable
The builtin types all already work this way, and that's a deliberate choice - my proposal is simply to document the behaviour as intentional, and fix the one case I know of in the standard library where we don't implement these semantics correctly (i.e. collections.Sequence).
The question of whether or not float and decimal.Decimal should be modified to have reflexive definitions of equality (even for NaN values) is actually orthogonal to the question of clarifying and documenting the expected semantics of containers in the face of non-reflexive definitions of equality.
Cheers, Nick.
-- Nick Coghlan | ncoghlan at gmail.com | Brisbane, Australia
- Previous message: [Python-Dev] PyObject_RichCompareBool identity shortcut
- Next message: [Python-Dev] PyObject_RichCompareBool identity shortcut
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]