[Nick Coghlan]
> As yet, I don't have a particularly firm opinion on whether or not block
> statements should support an 'else:' clause. And there are obviously a great
> many other questions to be answered about how block statements might work that
> are more important than this one.
>
> Still, I've been tinkering with some ideas for how to approach this, and
> thought
> I'd write them up for everyone else's consideration.
>
> Option 0:
> No else clause allowed. Figured I should mention this, since it is Guido's
> last reported inclination, and my total lack of use cases for the other
> options
> below suggests this is the best idea for an initial implementation.
The more I think about it the more this makes the most sense because
it is the easiest to understand.
> Option 1: mimic try, for, while semantics
> An 'else' clause on a block statement behaves like the else clause on for
> and while loops, and on try/except statements - the clause is executed only if
> the managed suite completes 'normally' (i.e. it is not terminated early due to
> an exception, a break statement or a return statement)
You'd have to define this very carefully. Because break is implemented
by passing StopIteration to the __next__ or __exit__ method (depending
on which alternative API we end up picking), and StopIteration is also
how these methods signal that the loop is over, it's a little tricky.
Assuming we go with __exit__ to pass an exception to the
iterator/generator, we could define that the else clause is executed
when the __next__ method raises StopIteration -- this would imply
exhaustion of the iterator from natural causes. This has the advantage
of matching the behavior of a for loop.
> Option 2: mimic if semantics
> An 'else' clause on a block statement behaves vaguely like the else clause
> on
> an if statement - the clause is executed only if the first suite is never
> entered, but no exception occurs (i.e. StopIteration is raised by the first
> call
> to next).
Strange because it's different from the behavior of a for loop, and
the block-statement doesn't feel like an if-statement at all. But I
could actually imagine a use case: when acquiring a lock with a
time-out, the else-clause could be executed when the acquisition times
out.
block locking(myLock, timeout=30):
...code executed with lock held...
else:
...code executed if lock not acquired...
But I'm not convinced that this shouldn't be handled with a try/except
around it all; the use case doesn't appear all that common, and it
scares me that when the lock isn't aquired, this happens entirely
silently when there is no else-clause.
> Option 3: iterator-controlled semantics
> The iterator is given the ability to control whether or not the else clause
> is executed (e.g. via an attribute of StopIteration), probably using option 1
> above as the default behaviour.
A slightly cleaner version would be to have a separate subclass of
StopIteration for this purpose. But I see serious problems with
explaining when the else-clause is executed, because it's too dynamic.
It does solve one problem with option 2 though: if there's no
else-clause, and ElseIteration is raised, that could become an error
rather than being ignored silently.
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
_______________________________________________
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
