[Python-Dev] Re: anonymous blocks

Neil Schemenauer nas at arctrix.com
Thu Apr 28 02:02:23 CEST 2005

On Wed, Apr 27, 2005 at 12:30:22AM -0700, Guido van Rossum wrote:
> I've written a PEP about this topic. It's PEP 340: Anonymous Block
> Statements (http://python.org/peps/pep-0340.html).

[Note: most of these comments are based on version 1.2 of the PEP]

It seems like what you are proposing is a limited form of
coroutines.  Just as Python's generators are limited (yield can only
jump up one stack frame), these coroutines have a similar
limitation.  Someone mentioned that we are edging closer to
continuations.  I think that may be a good thing.  One big
difference between what you propose and general continuations is in
finalization semantics.  I don't think anyone has figured out a way
for try/finally to work with continuations.  The fact that
try/finally can be used inside generators is a significant feature
of this PEP, IMO.

Regarding the syntax, I actually quite like the 'block' keyword.  It
doesn't seem so surprising that the block may be a loop.

Allowing 'continue' to have an optional value is elegant syntax.
I'm a little bit concerned about what happens if the iterator does
not expect a value.  If I understand the PEP, it is silently
ignored.  That seems like it could hide bugs.  OTOH, it doesn't seem
any worse then a caller not expecting a return value.

It's interesting that there is such similarity between 'for' and
'block'.  Why is it that block does not call iter() on EXPR1?  I
guess that fact that 'break' and 'return' work differently is a more
significant difference.

After thinking about this more, I wonder if iterators meant for
'for' loops and iterators meant for 'block' statements are really
very different things.  It seems like a block-iterator really needs
to handle yield-expressions.

I wonder if generators that contain a yield-expression should
properly be called coroutines.  Practically, I suspect it would just
cause confusion.

Perhaps passing an Iteration instance to next() should not be
treated the same as passing None.  It seems like that would
implementing the iterator easier.  Why not treat Iterator like any
normal value?  Then only None, StopIteration, and ContinueIteration
would be special.

Argh, it took me so long to write this that you are already up to
version 1.6 of the PEP.  Time to start a new message. :-)


More information about the Python-Dev mailing list