[Python-Dev] misbehaving __contains__

[Raymond Hettinger]

[Daniel Stutzbach]
> There are many places in the C implementation where a slot 
> returns an int rather than a PyObject.  There other replies 
> in this thread seem to support altering the signature of the 
> slot to return a PyObject. Is this setting a precedent that 
> _all_ slots should return a PyObject?

I hope not.

One cost of these hypergeneralizations is that it makes
Python slower.  

Also, it makes it harder to write code when you can no longer
count on simple predicates to return either True or False.


[tomer filiba]
> i see no reason it should behave differently than 
> __eq__ and the rest of comparison operators

The rest of the equality operators were a special case
to allow rich comparisons which were needed to implement
some vector arithmetic idioms.  

It was thought that those use case had enough benefit
to pay for the negative impacts:
* making the language more complex
* slowing everything down a bit.
* complicating the underlying implementation
* making the language more difficult to learn (rich operators
are harder than cmp)

Does making __contains__ return a PyObject have use cases
that are worth those costs?  

It is reminiscent of the ill-fated proposals to overrride 'and',
'or', 'is', and 'is not'.
A couple more questions about the proposal: 

If __contains__ returns 17 in Tomer's example,
what would "8 not in f" return?   

And, would we lose the nice relationship expressed by:

    for elem in container:
        assert elem in container

It looks like changing the semantics would introduce some weirdness.


Raymond