I think this is the kind of feature that can very easily be abused. Whenever I want to break out of a nested loop I take this as an opportunity to extract the loop into its own function and use the return statement to break out of the loop. IMO this is a lot better than having named or indexed loop control because a proper function can later be reusable, and it lets you explain why you need to return early in the docstring.

I agree with you that this feature can — and certainly will — be abused. But I don't think that's relevant: when you think about it, any feature can be abused. Example : variable are meant to allow a programmer to keep a reference to some data, using a meaningful label. However, have you never seen a piece of code where the variable names are so obscure you can't easily guess what they point to ? I guess you did . But variable aren't removed from any language for this reason !

The feature we're discussing now is, I think, a useful tool to be used parsimoniously when the need arises, like any other.

I can see several advantages to having it in the language, as opposed to building an ad-hoc function :

Globally, I think the indexed/labeled loops would be a useful tool in imperative programming. Some other code styles, such as functional programming, wouldn't need it, but isn't Python's policy to remain an open language to allow you to code however you like it best ? Think of other features, such as coroutines: they are a powerful tool, yet dangerous and easily misused (I'm mostly talking about the `yield` expression, witch can be used both to throw some output at the caller and to request input). However, coroutines did make it into Python, and I think they should remain there, because they can really be useful and powerful if used with care ! The same reasoning applies to our case.


TL;DR : consenting adults : the blame for misusing a feature is on the user, not on the language designer, especially when the feature is opt-in


Regards,

Alexis