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.