[Python-ideas] Non-boolean return from contains (original) (raw)

Alex Gaynor alex.gaynor at gmail.com
Mon Jul 26 04:20:59 CEST 2010

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

More information about the Python-ideas mailing list