[Python-Dev] Chaining try statements: eltry? (original) (raw)

Brett Cannon bcannon at gmail.com
Thu Jul 7 22:22:36 CEST 2005

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

More information about the Python-Dev mailing list