[Python-Dev] Why is the return value of contains coerced to boolean, but that of lt and the like is not? (original) (raw)

Ben Hoyt benhoyt at gmail.com
Mon Jul 15 05:34:08 CEST 2013

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

More information about the Python-Dev mailing list