Oh, just to show what I mean here with some code (same in both Python 2.x and 3.x):
----- from __future__ import print_function class C(object): def __contains__(self, x): print('__contains__({0!r})'.format(x)) return x def __lt__(self, x): print('__lt__({0!r})'.format(x)) return x c = C() print(42 in c) print(0 in c) print(c < 42) print(c < 0) ----- This prints the following: __contains__(42) True __contains__(0) False __lt__(42) 42 __lt__(0) 0 Whereas I'd kinda expect it to print: __contains__(42) 42 __contains__(0) 0 __lt__(42) 42 __lt__(0) 0 -Ben On Mon, Jul 15, 2013 at 12:21 PM, Ben Hoyt <benh...@gmail.com> wrote: > I'm curious why the return value of __contains__ is coerced to True or > False, whereas the return value of "normal" comparison operators like > __lt__ and the like are not. The latter return the value directly without > forcing it to be True or False. > > This makes overriding __contains__ significantly less flexible, so I'm > wondering why it's designed or implemented that way. (I believe it's the > cmp_outcome() function in Python/ceval.c that does this: > http://hg.python.org/cpython/file/db9fe49069ed/Python/ceval.c#l4545) > > For example, the "peewee" ORM overloads __lt__ and the like so it can map > Python expressions to SQL. But it can't do this with the "in" operator due > to the result of "x in y" always returning True or False in Python. So it > (ab)uses the "<<" operator to do this instead (See the peewee docs at > http://peewee.readthedocs.org/en/latest/peewee/querying.html#column-lookups > ). > > I'm sure there's a good reason for why "in" is different here, but I can't > see why right now. > > -Ben >
_______________________________________________ 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