"Barry A. Warsaw" wrote:
...
"PP" == Paul Prescod <paulp@ActiveState.com> writes:
PP> It looks like dubious hypergeneralization to me! <0.7 wink> PP> Seriously, does this "feature" ever make sense to apply to the PP> in operator?
I don't know; I wonder if "normal" people think of `in' as a chainable comparison operator or not.
If Tim, Guido, you and I are so completely out of sync with normal people that they will immediately intuit what we had to think hard about, we're in deep doo-doo!
You're not suggesting to change this are you?
I suggest a compile-time warning and then eventually we would make "in" non-chainable. Perhaps it should even have a different precedence than the other comparison operators. Tim's example looks reasonable to me: assert k in d1 == k in d2 And it would never, ever make sense to say: assert k in (d1==k) in d2 So why not interpret it the way that any normal human would: assert (k in d1) == (k in d2) I think that this is a subtle flaw in Python that just took a long time to manifest itself... And what about "1 is None == 2 is None"? If you saw that in a program (last week!) what would you have expected it to evalute to? Precedence levels exist to make code easier to read! -- Take a recipe. Leave a recipe. Python Cookbook! http://www.ActiveState.com/pythoncookbook