On Monday 20 October 2003 03:04 am, Guido van Rossum wrote: > FWIW, I partially withdraw my observation that reiterability is a > special case of cloneability. It is true that if you have > cloneability you have reiterability. But I hadn't realized that > reiterability is sometimes easier than cloneability! Hmmm, I thought I had shown a simple wrapper (holding a callable and args for it, as you show later) that implied how to wrap, at creation time, iterators built by iter(sequence) or by generators for reiterability (but not for cloneability). So, sure, cloneability is more general (you can use it to implement reiterability, but not VV) and harder to implement; reiterability IS "a special case" and thus it's less general but easier to implement. > But this doesn't make me any more comfortable with the idea of adding > reiterability as an iterator feature (even optional). Sure. "Relatively easy to implement" doesn't mean "should be in the language". Ease of learning, breadth and appropriateness of use, risk of misuse, ease of substitution if not in the language -- there are so many considerations! > With reiter() it becomes hard to explain what the input requirements > are for the function to work correctly; effectively, it would require > a "virginal" (== has never been used :-) reiterable iterator. So we Yes, very good point -- and possibly the explanation of why I never met a use case for reiterability as such. It's unlikely I want "an iterator that may already be partly consumed but I can restart from an unknown-to-me ``previous'' point in its lifetime" -- then I probably just want an iterable, just as you say. > might as well require a container! If you don't have a container but > you have a description of a series, Alex's Reiterable can easily fix > this: > > class Reiterable: > def __init__(self, func, *args): > self.func, self.args = func, args > def __iter__(self): > return self.func(*self.args) > > This should be called with e.g. a generator function and an argument > list for it. Yes, or the function that needs a callable + args anyway might require the callable and the args as its own arguments instead of wanting them packaged up as an iterable (an iterable's probably better if the typical use case is passing e.g. a list, though -- asking for the "iterator factory" callable might help when the typical use case is passing a generator). Yet another nail in the coffin of "reiterable as a concept in the language", methinks. Alex
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