On Tuesday 28 October 2003 04:33 pm, Guido van Rossum wrote: > I've lost context for the following thread. What is this about? I > can answer one technical question regardless, but I have no idea what > I'm promoting here. :-) Armin Rigo posted an URL to a C extension module he has recently developed, and used. That module is able to copy running instances of a generator. Currently, it does so by just "knowing", and type by type dealing with, several types whose instances could be values referred to by the generator's frame. I was suggesting extending this so that, when values of other types are met, instead of automatically failing (or, as I believe I recall Armin's extension does today, copying the reference rather than the value), the copy process would...: > > > Cool! Why don't you try copy.copy on types you don't automatically > > > recognize and know how to deal with, BTW? That might make this and Armin said that __copy__ seems weak to him but __deepcopy__ might not be: > > I will try. Note that only __deepcopy__ makes sense, as far as I can > > tell, because there is too much state that really needs to be copied and > > not shared in a generator (in particular, the sequence iterators from > > 'for' loops). So, now he went on to ask about __deepcopy__ and you answered: > > I'm not sure about how deep-copying should be defined for built-in > > types. Should a built-in __deepcopy__ method try to import and call > > copy.deepcopy() on the sub-items? This doesn't seem to be right. > > Almost -- you have to pass the memo argument that your __deepcopy__ > received as the second argument to the recursive deepcopy() calls, to > avoid looping on cycles. Now, if Armin's code can only provide __deepcopy__ and not __copy__, then it's probably of little use wrt the __copy__ functionality I talk about in PEP 323 (which I still must revise to take into account your feedback and Raymond's -- plan to get to that as soon as I've cleared my mbox) -- the memory and time expenditure is likely to be too high for that. It's still going to be a cool hack, well worth "publishing" as such, and probably able to be "user-installed" as the way deepcopy deals with generators even though generators themselves may not sprout a __deepcopy__ method themselves (fortunately, copy.copy does a lot of "ad-hoc protocol adaptation" -- it's occasionally a bit rambling or hard to follow, but often allows plugging in "third party copiers" for types which their authors hadn't imagined would be copied or deep copied, so that other innocent client code which just calls copy.copy(x) will work... essentially how "real" adaptation would work, except that registering a third-party protocol adapter would be easier:-). Alex
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