could itertools.cycle not make a copy of the iterable ?
Hi everyone, first I'm not quite sure if this is the right place to make this kind of suggestion/ask question but, `itertools.cycle` makes a copy of the iterable its given and as the note says: this may require significant auxiliary storage. Maybe I don't see the reason why this is nescessary but, shouldn't this work just as well: ``` def cycle(iterable): # cycle('ABCD') --> A B C D A B C D A B C D ... while iterable: for element in iterable: yield element ``` Instead of the current: ``` def cycle(iterable): # cycle('ABCD') --> A B C D A B C D A B C D ... saved = [] for element in iterable: yield element saved.append(element) while saved: for element in saved: yield element ```
On Wed, Jan 19, 2022 at 10:49 AM jerome via code-quality < code-quality@python.org> wrote:
This definitely isn't the right place, but I'll give you something to think about to help answer your question anyway.
Let's say I give you an iterable that looks like: ``` import random import typing def generate_random(limit: int = 5) -> typing.Generator[int, None, None]: for _ in range(limit): yield random.randint(0, 1_000_000) cycle(generate_random()) ``` How would your your revised version behave? How does that compare to the stdlib version? Instead of the current:
Thank you for the answer, yes I now see where the problem is. My reasoning was that in those case the responsibily should fall upon the user to make a list first instead of making a copy each time, but now I see that it can wait for ever in some cases. Sorry for posting in the wrong place !
If you use a generator instead of a string then you'll only loop once and wait forever. On Wed, Jan 19, 2022 at 11:49 AM jerome via code-quality < code-quality@python.org> wrote:
-- david stanek web: https://dstanek.com twitter: https://twitter.com/dstanek linkedin: https://www.linkedin.com/in/dstanek/
Thank for the answer David, waiting forever is indeed a problem. It seems obvious now .
On Wed, Jan 19, 2022 at 10:49 AM jerome via code-quality < code-quality@python.org> wrote:
This definitely isn't the right place, but I'll give you something to think about to help answer your question anyway.
Let's say I give you an iterable that looks like: ``` import random import typing def generate_random(limit: int = 5) -> typing.Generator[int, None, None]: for _ in range(limit): yield random.randint(0, 1_000_000) cycle(generate_random()) ``` How would your your revised version behave? How does that compare to the stdlib version? Instead of the current:
Thank you for the answer, yes I now see where the problem is. My reasoning was that in those case the responsibily should fall upon the user to make a list first instead of making a copy each time, but now I see that it can wait for ever in some cases. Sorry for posting in the wrong place !
If you use a generator instead of a string then you'll only loop once and wait forever. On Wed, Jan 19, 2022 at 11:49 AM jerome via code-quality < code-quality@python.org> wrote:
-- david stanek web: https://dstanek.com twitter: https://twitter.com/dstanek linkedin: https://www.linkedin.com/in/dstanek/
Thank for the answer David, waiting forever is indeed a problem. It seems obvious now .
participants (4)
-
David Stanek -
Ian Stapleton Cordasco -
jerome.guay＠protonmail.com -
Jérôme Guay