[Python-Dev] Chaining try statements: eltry?

[Brett Cannon]

On 7/7/05, Tim Peters <tim.peters at gmail.com> wrote:
> [Guido]
> > OTOH I don't particularly like code that requires flag variables;
> 
> Me neither; that's indeed why this one isn't a slam dunk.
> 
> > they often make me squirm because the same condition (flag) is
> > tested multiple times where it could be tested just once if more
> > sophisticated flow control (e.g. an else clause :) was available.
> 
> What burns me (far) more often in practice is "simulating" a
> multi-level `break` or `continue`.  Then multiple flag variables get
> introduced, set, and tested multiple times at multiple "logical indent
> levels" too.  That can also be viewed as stemming from a lack of more
> sophisticated flow control.  One-loop found-it-or-didn't kinds of flag
> variables have spatial locality that makes them (IME) quite easy to
> live with, in comparison.
> 
> > How would a PEP to *remove* this feature fare today?
> 
> Easy:  it would be rejected, but with a note that it should be
> reconsidered for Python 3000.
> 

Barry also reiterated this idea and I support removing them in Python
3000.  I do use them when I want to know when I break out of a loop
prematurely, but I am definitely not a typical use case for
experienced users since I basically learned how to program in Python
so I didn't have any baggage preventing me from not remembering they
existed.

Simplifying the basic control flow mechanisms is always good.  And as
Aahz pointed out, you can use exceptions to break out of a loop easily
enough and have code for only when you break out with the exception
(maybe we should add a ControlFlowException in Py3000 that all other
control flow exceptions, like StopIteration inherit from?).  In other
words they are not critical and not used frequently from what it
sounds like.  And even in the cases where they are used they can be
reworked to not need them without much hassle.

-Brett