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. | [EMAIL PROTECTED] +--------------------------------------+ _______________________________________________ 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