On Monday June 1, 2009, Scott David Daniels wrote: > Michael H. Goldwasser wrote: > > Chris, > > > > Thanks for your well-written reply. Your analogy to the > > complexities of other special methods is well noted. I'll accept > > the "small price for flexibility" that you note, if necessary. > > However, I still desire a cleaner solution. > > You seem to think that "deepcopy" is a well-defined concept. It is > not and cannot be. A copy that understands its own abstractions can > work, but sometimes a container is used as a simple abstraction, and > sometimes it is used as a container. The choice between the two is > not one of structure, but one of intent. A true deepcopy could > survive making a copy of the number 23, but might fail as it makes > a copy of None, True, or False. Certainly a dictionary might or > might not be copied, depending on how the dictionary is used. > > --Scott David Daniels > scott.dani...@acm.org
Hi Scott, It is clear from my original statement of the question that there is a need for classes to be able to customize their own semantics for supporting the deepcopy function. That is why the deepcopy function looks for a __deepcopy__ method within a class as a hook. My concern involves the challenge of providing a valid implementation for __deepcopy__ at one level of inheritance without being overly dependent on the internal mechanism used by ancestor classes in supporting deepcopy. I don't see how your comments address that question. Michael -- http://mail.python.org/mailman/listinfo/python-list
