At 01:58 PM 5/6/2005 +1000, Delaney, Timothy C (Timothy) wrote: >Personally, I'm of the opinion that we should make a significant break >(no pun intended ;) and have for-loops attempt to ensure that iterators >are exhausted. This is simply not backward compatible with existing, perfectly valid and sensible code. Therefore, this can't happen till Py3K. The only way I could see to allow this is if: 1. Calling __iter__ on the target of the for loop returns the same object 2. The for loop owns the only reference to that iterator. However, #2 is problematic for non-CPython implementations, and in any case the whole thing seems terribly fragile. So how about this: calling __exit__(StopIteration) on a generator that doesn't have any active blocks could simply *not* exhaust the iterator. This would ensure that any iterator whose purpose is just iteration (i.e. all generators written to date) still behave in a resumable fashion. Ugh. It's still fragile, though, as adding a block to an iterator will then make it behave differently. It seems likely to provoke subtle errors, arguing again in favor of a complete separation between iteration and block protocols.
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4