[Python-Dev] misbehaving contains (original) (raw)

tomer filiba tomerfiliba at gmail.com
Wed Jan 23 14:21:44 CET 2008

On Jan 23, 2008 3:19 AM, Raymond Hettinger <python at rcn.com> wrote:

[Steven Bethard]

>We've already lost this if anyone really wants to break it:: > > >>> class C(object): > ... def iter(self): > ... return iter(xrange(3)) > ... def contains(self, item): > ... return False [snip]

I'm more concerned about introducing an API where well-meaning attempts to code a contains override will implicitly shoot the toes off of client code that innocently assumes a somewhat sensible invariant relation between looping over elements in a container and those elements being in the container. The code for sets and frozensets makes that assumption, for example. And, when the code does break, the errors will be darned hard to find.

well, i don't see how limiting contains to returning booleans solves the problem you mentioned. what you're talking about is semantics, and that's always up to the programmer to get right. allowing contains to return a FooBar object won't change that a bit -- but it will allow me to construct expression objects more easily.

and, statements like

if x in y: pass

will work as expected, assuming the object returned by y.contains(x) has a proper bool/nonzero method. we're just deferring the type-cast to the point it's actually needed.

as per performance, i don't believe changing a slot method to return PyObject* instead of int would change anything... am i wrong?

-tomer

More information about the Python-Dev mailing list