> I see! So you want to be more prudent here than an ordinary copy > would be, and also disallow alternatives to __copy__ such as > __getinitargs__ or __getstate__/__setstate__ ...? Could you give > an example of an iterator class, which is "accidentally" copyable, but > "shouldn't" be for purposes of tee only? We discussed this before: if the state representing the iterator's position is a mutable object, copy.copy() will not copy this mutable object, so the two would share their state (or, more likely, part of their state). The example would be a tree iterator using a stack, represented as a list. > Yes, it IS worth pointing out that the idiom for using tee must > always be > a, b = tee(c) > and c is not to be used afterwards -- or equivalently > a, b = tee(a) > when, as common, there are no other references to a (even > indirectly e.g. via somebody holding on to a ref to a.next). Hmmm, > I wonder if that should go in my PEP, though, since it's more about tee > than about copy...? I think Raymond should add this to the tee() docs in big bold print. --Guido van Rossum (home page: http://www.python.org/~guido/)
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4