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.