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>
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4