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 <ncogh...@gmail.com> wrote: > 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
