I'm (weakly) +1 for the concept of for..else being confusing, weird, and somehow not quite suitable/useful for many use-cases where it feels like it should.

I'm -1 for each of the suggested improvements that I've understood so far.

I agree that the suggested 'ban' on changes in this area is probably not helpful, however it feels like a sloppy way of saying that changes to the syntax are very unlikely to be practical, for a couple of annoying, but important reasons.


    else:  # if not break:

Solution seems to highlight this.

The proposed convention of using comments here is clearly elective (nothing changes if you don't include the comment, although a style checker could require it, which would be a nice way of catching possible indentation errors)
Because this is implemented as a comment, and thus optional, it feels pointless because the original confusion is still there for people who don't bother to add the comment, and less experienced coders are less likely to know about the convention.

BUT it's probably as good as any other changes because...

I don't feel that, on balance, the cost of making a breaking syntax change to the language (having worked on huge python codebases, the cost of any breaking syntax change is just massive) is justified here, so whatever improvements may be made would probably have to still support the old syntax as-is.

The moment we retain the old syntax, then the new syntax becomes optional, and we're back in the problems with the comment approach.

The only route I can see to a workable outcome here is to implement the:

    "else if not break:"

clause as an optional alternate syntax, and update all the documentation to recommend using the new syntax over the old one (effectively silently deprecate for:...else:... syntax, but retain it indefinitely).

But this has issues, because some people will still use the old syntax, so we'll end up with lots of code out there using both variants, and that's as likely to add to the general confusion here as reduce it.


On Wed, Jul 22, 2020 at 9:26 AM Mathew Elman <mathew.elman@ocado.com> wrote:

On Wed, 22 Jul 2020 at 04:47, Paul Sokolovsky <pmiscml@gmail.com> wrote:

On Tue, 21 Jul 2020 17:48:35 -0700
Christopher Barker <pythonchb@gmail.com> wrote:

> how about:
> for something in some_iterable:
>     some_stuff_with_maybe_a_break
> else if not break:
>     something_more
> No new keywords :-)
> or:
> for something in some_iterable:
>     some_stuff_with_maybe_a_break
> else:  # if not break:
>     something_more

This is the most genius solution posted to this thread.

And if the thread didn't die after van Rossum's post, I don't cheer
hopes it would die now, but let me sprinkle in another "fresh"
thought. First let me remind how this thread started:

> ELSE-clause in FOR and WHILE has unclear syntax. I suggest new clause
> instead   

Then various people started to throw in variants of even more unclear
and confusing syntax (like "if" after "for"), with some percentage of
those people demonstrating not understanding how the original "else"

But consider following idea: if it's confusing, DO NOT USE it. You
don't hear that often, but: treat Python as a generic programming
language, not as a bag of tricks. The fact that most other languages
don't have extra clause after "for" is enough of a reason to not use it
in Python either.

The problem isn't that it is unclear, the problem is that it is misunderstood. If it was unclear what `for...else` means/does then yes, do-not-use would fix the problem. The fact that it can and is misunderstood as doing something else means that people have to learn to not use something that feels like it should be usable.

So why it exists at all then? It's there for people who don't find it
confusing, for very responsible use. As a random example, after
studying 2 (bytecode) Python compilers and having written my own (so I
know what code is generated from for-else), I no longer find it
confusing. I actually found 2 intuitive ways to use that construct, in
the very compiler mentioned - after all, if you eyeball a Python
compiler, you either know, or ready to learn, how all language
constructs work.

For anything else - clear ban. Everyone should consider that too. (But
please leave the language syntax alone (backwards compatibility, etc.),
at least that's a suggestion which comes out from van Rossum's post).

Frankly, saying that a part of a language that is frequently misunderstood, is never allowed to be improved is disappointing when the suggestion that it can be (somehow) has been so well received by everyone else.

> As for the "loop didn't run at all" case: Does anyone find a need for
> that? Personally, I've found that everytime I do some kind of check
> for an empty iterable before a loop, it was totally unnecessary.

I find the need for that regularly. And I use the obvious syntax which
everyone else uses:

if not seq:
    print("This page is intentionally left blank")
    for i in seq:

Any adhoc, confusing syntax someone may imagine to add, would go to the
same "DO NOT USE" category. So, I pray to van Rossum's answer that
something like that will never be added to the language. (Which is
hard to hang hopes on, given all the mess added recently.) 

Many people offering approaches is not muddling the thread. Clearly, most people here agree that `for...else` is confusing/unintuitive on it's own, and could be improved (not removed, but improved). The discussion was trying to find an improvement that people agree on as well. The reason there are so many offerings, is probably because everyone has had a similar thought about it in the past.

This email is confidential and may contain copyright material of members of the Ocado Group. Opinions and views expressed in this message may not necessarily reflect the opinions and views of the members of the Ocado Group.

If you are not the intended recipient, please notify us immediately and delete all copies of this message. Please note that it is your responsibility to scan this message for viruses.

References to the "Ocado Group" are to Ocado Group plc (registered in England and Wales with number 7098618) and its subsidiary undertakings (as that expression is defined in the Companies Act 2006) from time to time. The registered office of Ocado Group plc is Buildings One & Two, Trident Place, Mosquito Way, Hatfield, Hertfordshire, AL10 9UL.

Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-leave@python.org
Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/VLKG6NE4DOX43NZIHSTSSV5POM6AZ2NQ/
Code of Conduct: http://python.org/psf/codeofconduct/