This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author ncoghlan
Recipients ncoghlan
Date 2017-11-17.07:43:16
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1510904597.47.0.213398074469.issue32055@psf.upfronthosting.co.za>
In-reply-to
Content
(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).
History
Date User Action Args
2017-11-17 07:43:17ncoghlansetrecipients: + ncoghlan
2017-11-17 07:43:17ncoghlansetmessageid: <1510904597.47.0.213398074469.issue32055@psf.upfronthosting.co.za>
2017-11-17 07:43:17ncoghlanlinkissue32055 messages
2017-11-17 07:43:16ncoghlancreate