[issue10109] itertools.product with infinite iterator cause MemoryError.

Terry J. Reedy added the comment: Recipes for handling an infinite first iterator for product, or an infinite iterator for combinations (they could be similar), that use and build on the current functions, without the output order constraint, might be candidates for the recipe section. I will

[issue10109] itertools.product with infinite iterator cause MemoryError.

Tim Peters added the comment: Lucas, I largely agree, but it is documented that the various combinatorial generators emit items in a particular lexicographic order. So that is documented, and programs definitely rely on it. That's why, in an earlier comment, Terry suggested that perhaps `prod

[issue10109] itertools.product with infinite iterator cause MemoryError.

Lucas Wiman added the comment: It is quite thrifty with memory compared to the size of the search space O(n*k) memory for a search space of size O(n**k). I think a reasonable expectation for itertools.product is that it should _eventually_ reach any element in the search space. The only way to

[issue10109] itertools.product with infinite iterator cause MemoryError.

Raymond Hettinger added the comment: > What's the major objection to making all of the itertools functions > "maximally lazy"? It complicates the code and provides nearly zero benefit in practical use cases of the combinatoric functions. -- ___ Pyt

[issue10109] itertools.product with infinite iterator cause MemoryError.

Robert Xiao added the comment: It wouldn't be that complicated to have the combinatorial functions be lazy too - I feel like there's some value to be had there. What's the major objection to making all of the itertools functions "maximally lazy"? -- __

[issue10109] itertools.product with infinite iterator cause MemoryError.

Tim Peters added the comment: I see nothing wrong with combinatorial generators materializing their inputs before generation. Perhaps it should be documented clearly. It's certainly not limited to `product()`. For example, >>> for i in itertools.combinations(itertools.count(), 2): ... p

[issue10109] itertools.product with infinite iterator cause MemoryError.

Robert Xiao added the comment: I think this _is_ a bug. Most of the itertools are quite thrifty with memory, and exceptions are explicitly documented. The itertools generally only require memory proportional to the number of iterations consumed. However, `itertools.product` requires an enormou

[issue10109] itertools.product with infinite iterator cause MemoryError.

Lucas Wiman added the comment: I realize this is an old (and closed!) thread, but here are a few notes from running into this issue recently, working on a search problem with infinite iterators. First, note that yegle's recursive solution is not correct, since it exhausts the iterators: >>> d

[issue10109] itertools.product with infinite iterator cause MemoryError.

yegle added the comment: Found another example that shows horrible performance when using itertools.product: def gen(): l = [itertools.permutations(range(10)) for _ in range(10)] g = itertools.product(*l) for i in g: yield i A simple next() to this generator takes 16 seconds on my de

[issue10109] itertools.product with infinite iterator cause MemoryError.

Terry J. Reedy added the comment: A relatively simple change would be to allow the first iterable to be 'infinite', when repeat==1, by not calling tuple() on it. The reason for turning the iterables into concrete sequences is because they might not be reiterable. (cycle() does the same for th

[issue10109] itertools.product with infinite iterator cause MemoryError.

Sumudu Fernando added the comment: >>> tuple(itertools.cycle(enumerate(it)) for it in itertools.count()) ... TypeError: 'int' object is not iterable That is not what happens in the function, though! That would correspond to doing product(*itertools.count(2010)), but if you try that you wo

[issue10109] itertools.product with infinite iterator cause MemoryError.

Terry J. Reedy added the comment: Proposing an expansion of the definition of product() is a *completely* different issue from the validity of count() as an input. I answered correctly given the current definition of product(): it is not valid input. It is also not valid input to your propose

[issue10109] itertools.product with infinite iterator cause MemoryError.

Sumudu Fernando added the comment: I don't agree with the response to this. It is true that as implemented (at least in 2.7, I don't have 3.x handy to check) itertools.product requires finite iterables. However this seems to be simply a consequence of the implementation and not part of the "

[issue10109] itertools.product with infinite iterator cause MemoryError.

Terry J. Reedy added the comment: The input to itertools.product must be a finite sequence of finite iterables. itertools.count(startvalue) produces an infinite sequence of ints (which are not iterable). Passing the latter to the former causes the latter to run until memory is exhausted. You

[issue10109] itertools.product with infinite iterator cause MemoryError.

Changes by Éric Araujo : -- nosy: +eric.araujo ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.pyth

[issue10109] itertools.product with infinite iterator cause MemoryError.

Changes by Benjamin Peterson : -- assignee: -> rhettinger nosy: +rhettinger ___ Python tracker ___ ___ Python-bugs-list mailing list

[issue10109] itertools.product with infinite iterator cause MemoryError.

New submission from Jeong-Min Lee : According to the documentation, itertools.product is equivalent to nested for-loops in a generator expression. But, itertools.product(itertools.count(2010)) is not. >>> import itertools >>> (year for year in itertools.count(2010)) at 0x026367D8> >>> itertool