At 08:57 PM 10/17/03 -0700, Guido van Rossum wrote: > > Which, by the way, brings up a question: should iterator comps be > > reiterable? I don't see any reason right now why they shouldn't be, and > > can think of situations where reiterability would be useful. > >Oh, no. Not reiterability again. How can you promise something to be >reiterable if you don't know whether the underlying iterator can be >reiterated? Keeping a hidden buffer would be a bad idea. I think I phrased my question poorly. What I should have said was: "Should iterator expressions preserve the reiterability of the base expression?" I don't want to make them guarantee reiterability, only to preserve it if it already exists. Does that make more sense? In essence, this would be done by having an itercomp expression resolve to an object whose __iter__ method calls the underlying generator, returning a generator-iterator. Thus, any iteration over the itercomp is equivalent to calling a no-arguments generator. The result is reiterable if the base iterable is reiterable, otherwise not. I suppose technically, this means the itercomp doesn't return an iterator, but an iterable, which I suppose could be confusing if you try to call its 'next()' method. But then, it could have a next() method that raises an error saying "call 'iter()' on me first".
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