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.

Title: Line continuation after Boolean operation
Type: enhancement Stage: resolved
Components: Interpreter Core Versions: Python 3.7
Status: closed Resolution: rejected
Dependencies: Superseder:
Assigned To: Nosy List: eric.smith, rhettinger, veganaiZe
Priority: normal Keywords:

Created on 2020-10-11 17:59 by veganaiZe, last changed 2022-04-11 14:59 by admin. This issue is now closed.

Messages (4)
msg378441 - (view) Author: (veganaiZe) * Date: 2020-10-11 17:59
I can't do something like this (regarding the `or`)...

    if (not position.x == 0 and velocity == -1) or
            (not position.x == 500 and velocity == 1)

Nor this...

    if (not position.x == 0 and velocity == -1) or (
            not position.x == 500 and velocity == 1)

I have to do something like this...

    if (not position.x == 0 and velocity == -1) \
           or (not position.x == 500 and velocity == 1)

I would like to be able to do it the first way.
msg378442 - (view) Author: (veganaiZe) * Date: 2020-10-11 18:04
Actually, I can do it the second way.  I must have typo'd when testing (my apologies)...  But I'd still like to do it the first way. ☺
msg378467 - (view) Author: Raymond Hettinger (rhettinger) * (Python committer) Date: 2020-10-12 03:53
Sorry, I don't think this proposal has a chance.  

Python doesn't require statement terminators like ";" in C.  Accordingly, it needs to have a clean and consistent rule to close a statement.  The rule that has worked well for us it that a statement is terminated by a newline unless there is a line continuation character, or a colon to begin a new suite, or an open expression delimiter (parenthesis, square bracket or curly brace). 

Adding a special case exception to the rule might look nice but would complicate learning the language, and it would complicate the implementation as well.
msg378496 - (view) Author: Eric V. Smith (eric.smith) * (Python committer) Date: 2020-10-12 12:58
Agreed that this isn't likely to change.

If you have a concrete proposal for how the language parsing rules would change in order to support this, you should post it to the python-ideas mailing list.

If that discussion results in a consensus, then we can re-open this issue. But unless you have a very compelling rationale, I don't expect any language changes here.
Date User Action Args
2022-04-11 14:59:36adminsetgithub: 86173
2020-10-12 12:58:18eric.smithsetstatus: open -> closed

nosy: + eric.smith
messages: + msg378496

resolution: rejected
stage: resolved
2020-10-12 03:53:20rhettingersetnosy: + rhettinger
messages: + msg378467
2020-10-11 18:04:11veganaiZesetmessages: + msg378442
2020-10-11 17:59:27veganaiZecreate