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.

classification
Title: New clause in FOR and WHILE instead of ELSE
Type: enhancement Stage: resolved
Components: Interpreter Core Versions:
process
Status: closed Resolution: later
Dependencies: Superseder:
Assigned To: Nosy List: catrudis, eric.smith, rhettinger, terry.reedy, veky
Priority: normal Keywords:

Created on 2020-07-10 20:44 by catrudis, last changed 2022-04-11 14:59 by admin. This issue is now closed.

Messages (5)
msg373479 - (view) Author: catrudis (catrudis) Date: 2020-07-10 20:44
ELSE-clause in FOR and WHILE has unclear syntax. I suggest new clause instead:

if COND:
  ...
[elif COND:
  ...]
[else:
  ...]

This IF-clause like must be immediately after FOR- or WHILE-cycle (only comment allowed between). It looks like a regular IF, but COND is special.
COND may be "break", "pass" or "finally". "if break:" - if used break-operator to exit cycle. "if pass:" - cycle executed 0 times. "if finally:" - cycle executed 0 or more times ("pass-case"  is included in "finally-case"). For compatibility only "else:" means "if finally:".
It's compatible enhancement. No new keyword. There can be no combination "break", "pass" or "finally" after "if"/"elif:" in current version.
msg373486 - (view) Author: Eric V. Smith (eric.smith) * (Python committer) Date: 2020-07-10 21:21
You should bring this up on the python-ideas mailing list so that it gets more visibility.
msg373914 - (view) Author: Terry J. Reedy (terry.reedy) * (Python committer) Date: 2020-07-18 19:27
I think this should be closed as 'rejected'.

1. I am strongly opposed to giving keywords strongly context-dependent alternate meanings.  I also don't think that the proposal could be parsed.  Currently, 'if' introduces a new, independent statement, and making it dependent is not backwards compatible.

2. The proposal is unnecessary as the conditions can already be detected, and being explicit is much more flexible than the proposal.

for i001 in iterable: pass  # i001 is a new local name.

try:
    i001
    <loop executed at least once>
except NameError:
    <loop never executed>

for i in range(5):
    if i > 3:
        break001 = True  # New local.
        break

try:
    break001
    < loop broke>
except NameError:
    < loop exited normally>
msg373929 - (view) Author: Vedran Čačić (veky) * Date: 2020-07-19 05:27
I completely agree that we should reject this, but you commit a very frequent mistake in programming try-expressions. The problem is, if the first option contains a NameError, second option will be executed.

It should be:

    try: i001
    except NameError: <loop never executed>
    else: <loop executed at least once>

And similarly for break001. You see, dependent `else` is needed sometimes. But of course Guido already covered this. :-)
msg373931 - (view) Author: Raymond Hettinger (rhettinger) * (Python committer) Date: 2020-07-19 06:08
I see that this was already moved to the mailing list.  Am marking this as closed.  If the mail list discussion proves favorable, feel free to reopen.
History
Date User Action Args
2022-04-11 14:59:33adminsetgithub: 85444
2020-07-19 06:08:37rhettingersetstatus: open -> closed

nosy: + rhettinger
messages: + msg373931

resolution: later
stage: resolved
2020-07-19 05:27:02vekysetnosy: + veky
messages: + msg373929
2020-07-18 19:27:00terry.reedysetnosy: + terry.reedy
messages: + msg373914
2020-07-10 21:21:27eric.smithsetnosy: + eric.smith
messages: + msg373486
2020-07-10 20:44:00catrudiscreate