Hello,
Why not just use Raymond's suggestion nobreak as a replacement of the
else in loops and deprecate the else in Python 4?
There is at least a precedent when not equal <> was deprecated in favor
of != from Py2 to Py3.
We could do the same with else/nobreak between Py3 and Py4.
João Matos
On 22/07/2020 14:36, Mathew Elman wrote:
On Wed, 22 Jul 2020 at 13:45, Paul Moore <p.f.mo...@gmail.com
<mailto:p.f.mo...@gmail.com>> wrote:
On Wed, 22 Jul 2020 at 13:18, Mathew Elman <mathew.el...@ocado.com
<mailto: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/
_______________________________________________
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/7XKRFOR5IN5N3OH4ABU22ECI3KK7TJPR/
Code of Conduct: http://python.org/psf/codeofconduct/
