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 PySequence_Contains() 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
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4