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 the underlying iterators properly support copying, the copying of filter and
map iterators will be successful. If they don't support copying, the copying of
filter and map iterators should fail, and don't accumulate elements in the
tee() object.
But there are open questions.
1. This is a behavior change. What if any code depends on the current behavior?
This is silly, copy(filter) and copy(map) could just return the original
iterator if this is a desirable behavior.
2. Depending on the copy module in the method of the builtin type looks
doubtful. Should we implement copy.copy() in C and provide a public C API?
3. If make a copying of limited depth, shouldn't we use a memo as for
deepcopy() to prevent unwanted duplications? Otherwise the copied `map(func,
it, it)` would behave differently from the original. This example is not so
silly as looked.
4. Is it possible to implement the copying for all compound iterators? For
example the copying of chain() should change the state of the original object
(by using __setstate__), so that it makes copies of subiterators before using
them.
Perhaps all this deserves a PEP.
----------
_______________________________________
Python tracker <[email protected]>
<http://bugs.python.org/issue29897>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
