"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!