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 <rep...@bugs.python.org>
<http://bugs.python.org/issue29897>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

Reply via email to