On Sun, Jul 25, 2010 at 7:01 PM, Raymond Hettinger email@example.com wrote:
On Jul 25, 2010, at 2:32 PM, Michael Foord wrote:
x = y in z # where x is a non boolean.
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
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).