[Python-Dev] PEP 340 - For loop cleanup, and feature separation
greg.ewing at canterbury.ac.nz
Fri May 6 05:38:34 CEST 2005
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
for filename in filenames:
block opening(filename) as 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 +--------------------------------------+
More information about the Python-Dev