[Python-ideas] Non-boolean return from __contains__

[Guido van Rossum]

On Tue, Jul 27, 2010 at 9:02 AM, Alex Gaynor <alex.gaynor at gmail.com> wrote:
> On Tue, Jul 27, 2010 at 10:59 AM, Guido van Rossum <guido at python.org> wrote:
>> On Tue, Jul 27, 2010 at 3:29 PM, Mathias Panzenböck
>> <grosser.meister.morti at gmx.net> wrote:
>>> On 07/26/2010 04:20 AM, Alex Gaynor wrote:
>>>>
>>>> Fundamentally the argument in favor of it is the same as for the other
>>>> comparison operators: you want to do symbolic manipulation using the
>>>> "normal" syntax, as a DSL.  My example is that of a SQL expression
>>>> builder: SQLAlchemy uses User.id == 3 to create a clause where the ID
>>>> is 3, but for "id in [1, 2, 3]" it has: User.id.in_([1, 2, 3]), which
>>>> is rather unseamly IMO (at least as much as having User.id.eq(3) would
>>>> be).
>>>>
>>>
>>> This is a bad example for your wish because this code:
>>>>>> id in [1, 2, 3]
>>>
>>> translates into:
>>>>>> [1, 2, 3].__contains__(id)
>>>
>>> So it doesn't help that 'in' may return something else than a bool
>>> because the method is called on the wrong object for your purposes.
>>
>> Well that pretty much kills the proposal. I can't believe nobody
>> (including myself) figured this out earlier in the thread. :-(
>>
>> --
>> --Guido van Rossum (python.org/~guido)
>>
>
> Well, in my original example I wrapped the list with a SQLList()
> container class.  I thought of the issue before, but it hardly seems
> like a blocker, the numpy stuff is unaffected for example: they're not
> using a builtin container, and for myself I'm willing to wrap my lists
> to get the pretty syntax.

Well, writing "x in wrapper(y)" is hardly prettier than "contains(y,
x)", if you compare it to "x in y".

And it is certainly another thing that can go wrong in a non-obvious way.

-- 
--Guido van Rossum (python.org/~guido)