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
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4