On Wed, Sep 16, 2015, at 10:26, Chris Angelico wrote: > Quite probably never. But are there _any_ comparison operators which > are unchainable? If not, there's no reason to disallow 'in'
"in" suggests a relationship between objects of different types (X and "something that can contain X") - all the other comparison operators are meant to work on objects of the same or similar types. Why not make isinstance a comparison operator and have "1 instanceof int instanceof type"? Having chaining apply to things that are not *semantically* comparisons is just baffling. >; this is > the distinction between language-level features and usage > recommendations. All comparisons can be chained, and the semantics of > (X op1 Y op2 Z) will always be ((X op1 Y) and (Y op2 Z)) but with Y > evaluated only once. That definition is fairly simple, and even though > it's a little wordy, it makes perfect sense; and the rule "all > comparisons" is way WAY simpler than "this specific set of chainable > operators", It's the same thing - you've just named that set "comparisons". I don't think "in" is semantically a comparison at all. -- https://mail.python.org/mailman/listinfo/python-list
