On 15 July 2013 10:21, Ben Hoyt <benh...@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 | ncogh...@gmail.com | Brisbane, Australia _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
