New submission from Nick Coghlan <ncogh...@gmail.com>: (I thought there was an open low priority issue for this, but I can't find it, so filing a new one)
Currently, "in" and "not in" are classified as comparison operations in the language grammar, even though they're not actually documented as such (see https://bugs.python.org/issue28617 in relation to the latter point). Issue reports like https://bugs.python.org/issue30965, user questions like https://stackoverflow.com/questions/45180899/unexpected-result-from-in-operator-python/45180967, and behaviour puzzles like https://github.com/cosmologicon/pywat#operator-precedence suggest that the existing behaviour isn't particular intuitive to users. At the language design level (as far as I am aware), the benefit of treating "in" and "not in" as comparison operators is to ensure they share a precedence level with the other comparisons. While this is mostly a pretty harmless quirk, I think it's weird enough and useless enough for us to at least consider refining the Grammar such that "in" and "not in" live at the same level as other comparison operators, but *don't* participate in comparison chaining (i.e. "a == b in c" and "a in c == b" would both be syntax errors that required parentheses to disambiguate the desired associativity). ---------- messages: 306411 nosy: ncoghlan priority: low severity: normal status: open title: Reconsider comparison chaining for containment tests type: behavior versions: Python 3.7 _______________________________________ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue32055> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
