Le 04/12/2020 à 21:18, David Mertz a écrit :
I like the idea of named breaks, but I *hate* the idea of numerically
labeled breaks, whether numbered from the inside or from the outside.
On the occasions—which are actually relatively frequent—that I want to
break all the way out of an inner loop, I wind up using a sentinel
STOP variable. I know how to do that, but it's somewhat cumbersome
with a few lines of distracting code and a few pointless variables.
However, when I think about it, it's not a number of LEVELS I want,
but a particular identified loop that I want to escape from.
And yes, writing a function can be an approach to this. However, it's
also often cumbersome to reason through exactly every name that needs
to be captured as arguments, and often needs refactoring as the code
is developed. Abusing a try/except structure is another approach.
The problem with numbers, beyond just being harder to count out, is
that they are fragile under refactoring.
[…]
Overall, I'm definitely +1 on adding named breaks. It depends on the
syntax somewhat, but the concept would be useful. On the other hand,
it's come up numerous times over the years, and never quite happened.
And I've written programs perfectly well without it.
I agree with you that the point of `break x` — labeled or numbered — is
to target a specific loop to "jump" to, but I'm not comfortable with
introducing labels to Python.
The reason for this is that they look too much like identifiers, and
should, therefore, be bound to /something/, following Python's motto of
"everything is an object". I don't see what kind of an object could be
bound to that, what kind of API it would expose, how it could be
manipulated/re-affected, it behavior out of the loop…
On the other hand, we could have them be just labels, not identifiers,
and forbid them to be used out of `break x` statements. But then we'd
have two kinds of "used-defined names" evolving in separate dimensions;
I don't think that's a good thing, it would add too much confusion.
Maybe we could distinguish the two with some kind of semantics bound in
the name, start the loop labels with ":" or whatever; I don't like this
take on things either, but I like it better.
Now, the point of refactoring — good point indeed ! But I expect this
kind of problem already arises with regular breaks ?
However, I think that when adding code like you did (adding/removing a
loop to nested loops), you should read through all of the inner code, if
only to prevent variable name collisions, so there is really no problem
for conscientious programmers. Of course, if you're not cautious, you
risk bugging your program's control flow — from experience, the hardest
to debug — but then, we're back at the dangerous tool/responsible use
argument: if you can't handle it, don't use it, however the tool should
be there for those of us who can. I also think that in most cases, the
problem could be solved with a plain old comment next to the loop,
saying "warning, there exists a long break to this loop".
All this to say I'm not opposed to naming loops, but I really much
rather would have them numbered (outwards, if possible).
Regards,
Alexis
_______________________________________________
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/GUTVOI3EYXM4MBJLQDAAPKIZ3LVQGRV2/
Code of Conduct: http://python.org/psf/codeofconduct/
