[issue32055] Reconsider comparison chaining for containment tests

Change by Mark Dickinson : -- nosy: +mark.dickinson ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue32055] Reconsider comparison chaining for containment tests

Guido van Rossum added the comment: I agree that it would be less confusing if `in`/`not in` did not allow chaining, the occasional (surely very rare) useful example notwithstanding. Then again if we're going to forbid (or even discourage) unusual combinations we might also want to frown at

[issue32055] Reconsider comparison chaining for containment tests

Serhiy Storchaka added the comment: This had not been discussed. -- ___ Python tracker ___ ___ Python-bugs-list mailing list

[issue32055] Reconsider comparison chaining for containment tests

Tal Einat added the comment: Has this been discussed on python-dev? If so, what was the result? -- nosy: +taleinat ___ Python tracker ___

[issue32055] Reconsider comparison chaining for containment tests

Serhiy Storchaka added the comment: On other hand, beginners are confused even by chained "==". There are regular reports about this on the tracker and questions on Python-related resources. I have found the chained "in" is useful in the following case

[issue32055] Reconsider comparison chaining for containment tests

Serhiy Storchaka added the comment: I'm reading the list of most rated in a week questions on StackOverflow (https://python-weekly.blogspot.com/), and it seems to me that the question about chained "in" and "not in" is raised every few months. This may be the one

[issue32055] Reconsider comparison chaining for containment tests

Nick Coghlan added the comment: If we do decide to do this, I'm inclined to eventually make the change at the Grammar level rather than the AST level. Current: comparison: expr (comp_op expr)* comp_op: '<'|'>'|'=='|'>='|'<='|'<>'|'!='|'in'|'not' 'in'|'is'|'is'

[issue32055] Reconsider comparison chaining for containment tests

Serhiy Storchaka added the comment: PR 4501 makes the parser emitting a SyntaxWarning for chained `in` and `not in` comparison operators. In future it can be turned into a SyntaxError. But this should be first discussed on Python-Dev. --

[issue32055] Reconsider comparison chaining for containment tests

Change by Serhiy Storchaka : -- keywords: +patch pull_requests: +4439 stage: -> patch review ___ Python tracker ___

[issue32055] Reconsider comparison chaining for containment tests

Nick Coghlan added the comment: Just a note on why I find "a in b < c" unintuitive, even for sets: my brain initially wanted to read it as equivalent to "a in b & c". -- ___ Python tracker

[issue32055] Reconsider comparison chaining for containment tests

Nick Coghlan added the comment: Aye, there are definitely cases where the answer isn't nonsense. Even for sets though, "a in b < c" isn't an intuitive spelling of "a in b and b < c" the way that "a < b < c" is an intuitive spelling of an ordering relation. Hence filing

[issue32055] Reconsider comparison chaining for containment tests

Serhiy Storchaka added the comment: `a in b < c` makes sense if b and c are sets. -- nosy: +serhiy.storchaka ___ Python tracker

[issue32055] Reconsider comparison chaining for containment tests

Nick Coghlan added the comment: https://bugs.python.org/issue14247 is another older issue related to this point (again related to a user finding the current behaviour genuinely unintuitive) -- ___ Python tracker

[issue32055] Reconsider comparison chaining for containment tests

New submission from Nick Coghlan : (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