On 20/05/16 00:51, Gregory Ewing wrote:
It's not so bad with "else" because you need to look back
to find out what condition the "else" refers to anyway.
With my tongue only slightly in my cheek, if it was desirable to
"fix"/clarify this syntax then I would suggest adding some optional
(existing) trailing keywords to 'else' in this context that spells it out:
for item in seq:
if foo(item):
break
else if not break:
nomatch()
I would rule out "elif not break" - this is just about adding additional
trailing words to existing syntax to spell it out (which might be a good
teaching aid as well as turn into personal preferred style).
I guess that it _could_ be a syntax error to reference "break" if the
for/while loop does not contain the keyword in its body - this could
actually address one of the "confusing" things mentioned in this thread,
like:
seq = []
for item in seq:
pass
else if not break:
pass
# Syntax error - "break" referenced in "for/else" clause but not present
in loop body.
Someone also pointed out that there are other flow control mechanisms
that could prevent the 'else' from being executed: "return" and "raise".
One could extend the above to allow one or more of those to be specified:
else if not break or return or raise:
That looks like a lot of noise, but again it could help make code more
explicit (both to the human reader, and to a compile-time check):
for item in seq:
if foo(item):
break
if bar(item):
return
else if not return:
pass
# Syntax error - extended "for/else" clause does not reference "break",
which exists in loop body.
I would _not_ suggest that the above should ever mean "if it doesn't
return, this code is executed regardless of whether 'break' happened" -
one would remove the 'else' clause altogether for that.
"raise" is more problematic as an exception can always be raised by
pretty much _anything_ in the body without the keyword being present.
Perhaps "or raise" is just a completely benign, optional keyword for the
completists. Or perhaps it's simply not mentioned at all and is always
implied (as is true of exceptions in other constructs such as plain
"if/else", and just generally).
The additional keywords would effectively just be a static checked
filter - the original bare "else" would effectively mean "else if not
any_flow_control_out_of_the_loop" (which is what it means today).
In summary: Adding the "if not" extension is the suggestion, with
"break" as the filter. "return" as an additional filter is a possibility
which may add something, "raise" as an additional filter is a
possibility which probably doesn't add anything (and may actually be
distracting).
I'm not entirely sure if _I_ like this yet (there are some things I've
suggested that I like and some I'm not sure about and some I don't like
but I've mentioned them anyway) - I'm just throwing it out there ;)
E.
--
https://mail.python.org/mailman/listinfo/python-list
