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/
