On Wed, 22 Jul 2020 at 13:45, Paul Moore <p.f.mo...@gmail.com> wrote:
> 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.
I don't think this would be any more confusing than `for...else` already
is, and `while...elif...else` still seems like a logical extension of
`while...else`.
x=0
while x < 10:
delta = get_delta(x)
if delta == 0:
break
x += delta
elif x%2:
print(f"{x} is odd and > 10")
else:
print(f"{x} is even and > 10")
> And to have the elif after a loop be limited to a
> different set of conditions than "ordinary" elif would *also* be
> really confusing.
>
Absolutely! I would not suggest limiting it to any special cases. Hence why
I split up the change. Adding a way to *also* use the elif to check the
state of the loop is a separate discussion. Be that by using `break` as a
special boolean or some other way.
> > 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):
> ...
>
That is fair enough, like I have said I am not attached (though others may
be) to the idea of using `break` as a special boolean. Would it be more
feasible to have a variable that persists beyond the scope of the loop and
is not `break` but something else? For example, and this is not 100%
serious but something like : `iter.broken`, `iter.enetered` etc.
>
> 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.
>
Good point, I think this is a well made argument for *not* making `break`
have a second meaning.
--
Notice:
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-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/2XU5PSUKBYR3PA6SY635G4XSLELPMXXX/
Code of Conduct: http://python.org/psf/codeofconduct/
