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