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
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