[Python-Dev] PEP 340 - For loop cleanup, and feature separation

[Greg Ewing]

I'm still bothered by the idea of for-loops not participating
in the new generator finalization protocol.

It's all very well to say that iterators designed for block
statements shouldn't be used in for-loops, but there may
be more subtle cases to consider, such as

   def file_frobulations(filenames):
     for filename in filenames:
       block opening(filename) as f:
         yield something_derived_from(f)

This is clearly intended to be a normal iterator, not a
block iterator, and thus should be usable in a for-loop.
But if for-loops don't use the finalization protocol,
it won't be guaranteed to work correctly.

So I think that, in the interests of least surprise,
for-loops should provide the same finalization promises
as block statements.

If that is done, it becomes easier to decide whether
the block statement should loop. The answer is probably
no: If you're writing a loop, you use a for-statement;
if you're not, you use a block-statement. This helps
to clearly differentiate the two, and provide
justification for having two statements.

I'm also starting to like the idea of having a
completely separate protocol for block-statements,
and an adaptor of some kind for using generators to
implement them. We would then have two *totally*
separated new features:

1) A block-statement, and an associated protocol
    designed specifically for it, independent of
    any existing protocols.

2) A mechanism for passing values and exceptions into
    generators, which is useful in its own right and
    already has use cases.

With the addition of an adaptor between the block
protocol and the iterator protocol, which can be
implemented *without* needing any further features,
these two features then combine synergistically to
give you block iterators implemented by generators.

This makes a lot more sense to me than trying to
warp the iterator protocol to make it into a block
protocol as well. Let's keep the two things orthogonal.

-- 
Greg Ewing, Computer Science Dept, +--------------------------------------+
University of Canterbury,	   | A citizen of NewZealandCorp, a	  |
Christchurch, New Zealand	   | wholly-owned subsidiary of USA Inc.  |
greg.ewing at canterbury.ac.nz	   +--------------------------------------+