[Python-Dev] Why is the return value of contains coerced to boolean, but that of lt and the like is not? (original) (raw)
Nick Coghlan ncoghlan at gmail.com
Mon Jul 15 02:45:20 CEST 2013
- Previous message: [Python-Dev] Why is the return value of __contains__ coerced to boolean, but that of __lt__ and the like is not?
- Next message: [Python-Dev] Why is the return value of __contains__ coerced to boolean, but that of __lt__ and the like is not?
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
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
- Previous message: [Python-Dev] Why is the return value of __contains__ coerced to boolean, but that of __lt__ and the like is not?
- Next message: [Python-Dev] Why is the return value of __contains__ coerced to boolean, but that of __lt__ and the like is not?
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]