Nick Coghlan wrote:
Paul Moore wrote:
2009/6/20 Terry Reedy <tjreedy@udel.edu>:
I am looking at the issue from the caller's viewpoint. I have an iterator constructor and I want to use an existing function that requires a re-iterable. OK. But how many functions require a re-iterable? It doesn't seem to me to be a common requirement.
And if they did, how often would it be a problem to construct a list?
I see your point, but I can't imagine it's a common need. But your experience may differ.
Mostly avoiding this discussion, but I think the use cases are even narrower than that.
1. I've never seen a function parameter spec'ed as iterable vs reiterable. It's always iterable vs sequence.
The latter could be over-spec'ed because people are used to that being the choice, or because 'sequence' is being used as a synonym for 'reiterable' even though it implies more than is needed.
2. "Sequence" implies a lot more than "reiterable" does: it also implies length, containment test support, random access. So any idea focused solely on reiterability misses out on those extra features.
Which may or may not be needed. def pairs(finite_reiterable) for i in finite_reiterable: for j in finite)reiterable: return (i,j) is a simple function for which 'finite_reiterable' is exactly the appropriate spec. The issue is whether it is best to wrap it internally (inline) with a generic list(it) or to let the caller special-case iterator constructors.
3. Terry's idea also assumes a deterministic data source. An iterator with a random element or a data feed from the real world can't be used with it (because the original sequence can't be reproduced without saving it).
Yes.
4. The only reliable way to make an arbitrary iterator reiterable is to cache the results in memory, but we already have a way to do that (i.e. store it in a list or tuple)
Which I mentioned in my original post. I specificlly considered how to make iterator constructors, more common in 3.x, reiterable *without* storing everything in memory. Avoiding such storage is why map, filter, range, for example, were changed. So it hardly seems like an oddball aim.
5. For iterator based cases where only *some* of the values need to be kept around rather than all of them, then the algorithm implementation should be redesigned so it can make effective use of itertools.tee()
As I understand, everything goes into the tee and everything comes out in order, so I don't understand what you mean keeping some value.
In other words, this strikes as a fairly complicated solution to a rather limited problem.
I believe someone else though it was too simple for the stdlib ;-) The solution is a variation of functools.partial. I would certainly look for more concrete use cases, perhaps in the stdlib, before seriously proposing it for inclusion. Terry Jan Reedy