On Wed, 22 Jul 2020 at 13:18, Mathew Elman <mathew.el...@ocado.com> wrote: >> Ones that retain else on loops are bad because >> they end up providing two (typically equally confusing) ways of doing >> things. > > I don't think this is the case. I agree that adding an alternative to `else` > just to have an alternative is not a good fix, but adding explicit ways to > refer to when breaking from the loop would make the use of `else` as it > already is clearer. > > For example, breaking the change into 2 parts: > 1. Adding `elif` to the `for...else` and `while...else` statements seems a > logical extension. Guido has even said that the else in loops was invented by > reasoning the connection of `if` to `while` (and then `while` to `for`). > Perhaps this should be in its own discussion so as not to clutter this thread?
IMO, allowing for ... elif x == 2: do something to mean "if we didn't break out of the loop, and x is 2" would be really confusing. And to have the elif after a loop be limited to a different set of conditions than "ordinary" elif would *also* be really confusing. > 2. Adding a way to use this new `elif` to check the state of the loop. > Possibly including if it was broken out of or if it was never entered. Such > as having special local variables that are only defined in the block/frame of > the loop. Same logic here - if we allow "elif not break" (for example), it would be really confusing to *arbitrarily* only allow that if the elif is attached to a loop. So we need to define what if x == 2: do something elif not break: what? means in general code. And that means inventing rules for the scope of "break as an expression". And in a similar vein, what does it mean to pass "break" to a function? def invert(flag): return not flag for ... elif invert(break): ... It's not that any of these things are *reasonable* to do, it's that all the special cases needed to disallow them would be confusing, and if we *didn't* disallow them, all of the rules needed to give them meaning in (conceded) unreasonable places would be confusing. The trick here is *not* to look at the case that you expect the construct to be used in - obviously it'll look good to you in that context, if you like the idea at all. What you need to look at is all the other ways it could be applied, and verify that the costs justify the improvement that you saw when you first encountered the idea. Paul _______________________________________________ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/2I6JLL63DM2RG5MKQUJUOO6RQBAVRQV7/ Code of Conduct: http://python.org/psf/codeofconduct/