Challenge supporting custom deepcopy with inheritance
Michael H. Goldwasser
goldwamh at slu.edu
Mon Jun 1 21:02:06 CEST 2009
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.Daniels at Acm.Org
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.
More information about the Python-list