[Python-ideas] Non-boolean return from __contains__

Alex Gaynor alex.gaynor at gmail.com
Tue Jul 27 18:02:20 CEST 2010


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.

Alex

-- 
"I disapprove of what you say, but I will defend to the death your
right to say it." -- Voltaire
"The people's good is the highest law." -- Cicero
"Code can always be simpler than you think, but never as simple as you
want" -- Me



More information about the Python-ideas mailing list