[Python-ideas] Non-boolean return from __contains__

[Alex Gaynor]

On Sun, Jul 25, 2010 at 7:01 PM, Raymond Hettinger
<raymond.hettinger at gmail.com> wrote:
>
> On Jul 25, 2010, at 2:32 PM, Michael Foord wrote:
>>
>>
>> x = y in z          # where x is a non boolean.
>>
>> Yuck.
>>
>
>
> How is it any worse than:
>
>
>  x = y > z # where x is a non boolean
>
> And all the other operators that already do this?
>
>
> Terrible sales technique:  "how is this any worse than ..." ;-)
> Other operations such as rich comparisons have
> complicated our lives but had sufficient offsetting benefits
> than made them more bearable.  Rich comparisons cause
> no end of trouble but at least they allow the numeric folks
> to implement some well studied behaviors than have proven
> benefits in their domain.
> In contrast, this proposal offers almost zero benefit to offset
> the pain it will cause.  The OP didn't even offer a compelling
> use case or a single piece of code that wouldn't be better
> written with a normal method.
> No existing code expects "in" to return a non-boolean.
> A lot of code for containers or that uses containers implicitly
> expects simple invariants to hold:
>    for x in container:
>        assert x in container
>
>
> Raymond
>
> P.S.  With rich comparisons, we've lost basics assumptions
> like equality operations being reflexsive, symmetric, and
> transitive.   We should be cautioned by that experience
> and only go down that path again if there is a darned good reason.

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).

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