Challenge supporting custom deepcopy with inheritance

[Michael H. Goldwasser]

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

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