On Jan 23, 2008 3:19 AM, Raymond Hettinger <[EMAIL PROTECTED]> 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
_______________________________________________
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
