[Python-Dev] Suirprise!

Paul Prescod paulp@ActiveState.com
Sun, 22 Apr 2001 20:04:21 -0700


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