On 7/7/05, Tim Peters <[EMAIL PROTECTED]> 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 _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com