[Python-Dev] Unhashable objects and contains() (original) (raw)
Georg Brandl g.brandl at gmx.net
Sun Jun 4 00:52:02 CEST 2006
- Previous message: [Python-Dev] Unhashable objects and __contains__()
- Next message: [Python-Dev] Unhashable objects and __contains__()
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Collin Winter wrote:
I recently submitted a patch that would optimise "in (5, 6, 7)" (ie, "in" ops on constant tuples) to "in frozenset([5, 6, 7])". Raymond Hettinger rejected (rightly) the patch since it's not semantically consistent. Quoth:
Sorry, this enticing idea has already been explored and rejected. This is issue is that the transformation is not semanatically neutral. Currently, writing "{} in (1,2,3)" returns False, but after the transformation would raise an exception, "TypeError: dict objects are unhashable". My question is this: maybe set/frozenset.contains (as well as dict.contains, etc) should catch such TypeErrors and convert them to a return value of False? It makes sense that "{} in frozenset([(1, 2, 3])" should be False, since unhashable objects (like {}) clearly can't be part of the set/dict/whatever. I am, however, a bit unsure as to how contains() would be sure it was only catching the "this object can't be hash()ed" TypeErrors, as opposed to other TypeErrors that might legimately arise from a call to some hash() method. Idea: what if Python's -O option caused PySequenceContains() to convert all errors into False return values?
It would certainly give me an uneasy feeling if a command-line switch caused such a change in semantics.
Georg
- Previous message: [Python-Dev] Unhashable objects and __contains__()
- Next message: [Python-Dev] Unhashable objects and __contains__()
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]