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
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
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
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.
--
___
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"?
--
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):
...
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
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:
>>>
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
Sumudu Fernando sumu...@gmail.com 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
Terry J. Reedy tjre...@udel.edu 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
Sumudu Fernando sumu...@gmail.com 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
Terry J. Reedy tjre...@udel.edu 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()
Changes by Éric Araujo mer...@netwok.org:
--
nosy: +eric.araujo
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue10109
___
___
Python-bugs-list
Terry J. Reedy tjre...@udel.edu 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
New submission from Jeong-Min Lee false...@gmail.com:
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))
generator
Changes by Benjamin Peterson benja...@python.org:
--
assignee: - rhettinger
nosy: +rhettinger
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue10109
___
17 matches
Mail list logo
