Tim Peters wrote:
...
I suggest a compile-time warning and then eventually we would make "in" non-chainable.
An incompatible language change would, I think, need to go thru the __future__ (however spelled) business.
??? My understanding was that __future__ was a way of sneaking in a cool feature earlier than it would have been possible to deploy it given strict gradual evolution contraints. But disallowing confusing uses of "in" is not a feature and nobody is in a big hurry to see it happen. I wouldn't mind waiting a year or two until everyone has had a chance to clean up their code.
... For example, it's not a stretch at all anymore to believe that someone *is* using
a in b in c
now deliberately for its
(a in b) and (b in c)
meaning. Perfectly natural if, e.g., you use __contains__ to implement an "is subset of" relation.
The following grammar would preserve it and outlaw confusing cases: comparison: in_comparison | is_comparison | math_comparison math_comparison: expr (math_comp_op expr)* in_comparison: expr ('in' | 'not' 'in' expr)* is_comparison: expr ('is' | 'is' 'not' expr)* math_comp_op: '<'|'>'|'=='|'>='|'<='|'<>'|'!=' -- Take a recipe. Leave a recipe. Python Cookbook! http://www.ActiveState.com/pythoncookbook