An incompatible language change would, I think, need to go thru the __future__ (however spelled) business.
[Paul]
???
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.
That's not what PEP 236 says. __future__ is about *incompatible* language changes, period. "Cool" has nothing to do with it. If you're making something illegal that used to work, that's an incompatible change, and people get at least one release cycle in which it continues to work without change but with warnings. They can also ask for future behavior early via using an explicit future-statement in the module. Although in this case I guess the "future behavior" is just to turn the wng msg into a SyntaxError, in which case the __future__ machinery does seem like overkill.
But disallowing confusing uses of "in" is not a feature
PEP 236 is about incompatible changes, not features. It so happens that the first use (nested scopes) was a new feature that *could* break old code, so was both a new feature and an incompatible change.
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.
I'd rather not nag people at all if this is the only time it's come up in a decade <wink>. We've all got too much to do.
... The following grammar would preserve it [chaining "in"] 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: '<'|'>'|'=='|'>='|'<='|'<>'|'!='
Did you try that grammar? I'm skeptical that it works, since at first glance the comparison production appears to require arbitrary lookahead to determine which xxx_comparison case obtains. But if so, I'm sure it can be repaired. Whether it *should* be is a different matter I'll leave to Guido to Pronounce on.