[Python-Dev] Why is the return value of __contains__ coerced to boolean, but that of __lt__ and the like is not?

[Ben Hoyt]

Thanks, Nick -- that's helpful info. Writing such a PEP is a nice idea, but
I think it'd be beyond me (I'm not familiar enough with CPython internals,
protocols, etc).

Can you explain what you mean by "symmetric protocol rather than the
current only-controlled-by-the-container behaviour"?

-Ben


On Mon, Jul 15, 2013 at 12:45 PM, Nick Coghlan <ncoghlan at gmail.com> wrote:

> On 15 July 2013 10:21, Ben Hoyt <benhoyt at gmail.com> wrote:
> > I'm sure there's a good reason for why "in" is different here, but I
> can't
> > see why right now.
>
> It depends on what you mean by "good reason" - PEP 207 (which is what
> allows arbitrary objects to be returned from comparison operations)
> was entirely about replacing __cmp__ with the rich comparison methods,
> it doesn't mention __contains__ at all.
>
> At this point the main limitations are backwards compatibility (having
> existing containment tests suddenly start returning anything other
> than True or False would be problematic), along with the signature of
> CPython's sq_contains slot (it returns an integer rather than a
> PyObject pointer).
>
> Accordingly, to convert containment testing to a rich comparison
> operation would require a new protocol. That said, there is potential
> value in redefining containment in terms of a symmetric protocol
> (rather than the current only-controlled-by-the-container behaviour),
> so such a PEP may be worth writing. (it would initially be a topic for
> python-ideas rather than python-dev, though)
>
> Cheers,
> Nick.
>
> --
> Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20130715/4d5d5834/attachment.html>