Nick Coghlan wrote:
Paul Moore wrote:
2009/6/20 Terry Reedy email@example.com:
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.
- 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.
- "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.
- 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).
- 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.
- 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