[issue29897] itertools.chain behaves strangly when copied with copy.copy

New submission from Michael Seifert: When using `copy.copy` to copy an `itertools.chain` instance the results can be weird. For example >>> from itertools import chain >>> from copy import copy >>> a = chain([1,2,3], [4,5,6]) >>> b = copy(a) >>> next(a) # looks okay 1 >>> next(b) # jumps to t

[issue29897] itertools.chain behaves strangly when copied with copy.copy

Changes by Raymond Hettinger : -- assignee: -> rhettinger nosy: +rhettinger ___ Python tracker ___ ___ Python-bugs-list mailing list

[issue29897] itertools.chain behaves strangly when copied with copy.copy

Raymond Hettinger added the comment: Humph, that is definitely not the expected result. The itertools copy/reduce support has been a never-ending source of bugs and headaches. It looks like the problem is that __reduce__ is returning the existing tuple iterator rather than a new one: >>> a =

[issue29897] itertools.chain behaves strangly when copied with copy.copy

Serhiy Storchaka added the comment: chain(x) is a shortcut for chain.from_iterable(iter(x)). Neither copy.copy() nor __reduce__ don't have particular relation to this. Consider following example: >>> from itertools import chain >>> i = iter([[1, 2, 3], [4, 5, 6]]) >>> a = chain.from_iterable(i

[issue29897] itertools.chain behaves strangly when copied with copy.copy

Changes by Raymond Hettinger : -- assignee: rhettinger -> ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http

[issue29897] itertools.chain behaves strangly when copied with copy.copy

Serhiy Storchaka added the comment: This issue is related to the behavior of other composite iterators. >>> from copy import copy >>> it = map(ord, 'abc') >>> list(copy(it)) [97, 98, 99] >>> list(copy(it)) [] >>> it = filter(None, 'abc') >>> list(copy(it)) ['a', 'b', 'c'] >>> list(copy(it)) []

[issue29897] itertools.chain behaves strangly when copied with copy.copy

Michael Seifert added the comment: Just an update what doesn't work: just overriding the `__copy__` method. I tried it but it somewhat breaks `itertools.tee` because if the passed iterable has a `__copy__` method `tee` rather copies the iterator (=> resulting in a lot of unnecessary memory ov

[issue29897] itertools.chain behaves strangly when copied with copy.copy

Serhiy Storchaka added the comment: Just for example there is a patch that implements in Python deeper copying for itertools.chain objects. I doesn't mean pushing it, it is too complicated. I have wrote also slightly simpler implementation, but it doesn't work due to the behavior of copied map

[issue29897] itertools.chain behaves strangly when copied with copy.copy

Raymond Hettinger added the comment: Serhiy, feel free to take this in whatever direction you think is best. -- assignee: -> serhiy.storchaka ___ Python tracker ___

[issue29897] itertools.chain behaves strangly when copied with copy.copy

Kristján Valur Jónsson added the comment: It is a tricky issue. How deep do you go?what if you are chaining several of the itertools? Seems like we're entering a semantic sinkhole here. Deepcopy would be too deep... The original copy support in these objects stems from the desire to support pick

[issue29897] itertools.chain behaves strangly when copied with copy.copy

Serhiy Storchaka added the comment: Yes, this issue is tricky, and I don't have . If implement __copy__ for builtin compound iterators I would implement filter.__copy__ and map.__copy__ something like: def __copy__(self): cls, *args = self.__reduce__() return cls(*map(copy, args)) If

[issue29897] itertools.chain behaves strangly when copied with copy.copy

Raymond Hettinger added the comment: > Perhaps all this deserves a PEP. If Serhiy and Kristján are on a course of action, that will suffice. Copying iterators is an esoteric endeavor of interest to very few users (no one has even noticed until now). -- __