[Tutor] Challenge supporting custom deepcopy with inheritance

Alan Gauld alan.gauld at btinternet.com
Mon Jun 1 09:27:00 CEST 2009

"Kent Johnson" <kent37 at tds.net> wrote 

> > Yesterday, I posted a question to python-list involving custom
> > deepcopies in an inheritance hierarchy. I haven't received any
> ISTM that in general B.__deepcopy__() should call 
> A.__deepcopy__() to do the "A" part of the work. In your example, 
> this won't work because A.__deepcopy__() assumes that 
> subclasses have a one-argument constructor. So, I would 
> say that B is not fulfilling the contract assumed by A.

I've been trying to think of a clear way to reply to this but kept 
getting sucked into discussions of the Liskoff Substitution Principle 
and Law of Demeter and such. Kent's explanation is much clearer!

But this example highlights a real problem (IMHO) with dynamic 
OOP languages like Python. You can write classes that examine 
themselves at runtime and manipulate attributes that were actually
provided by subclasses (or even by the application writer!). This 
makes any attempt at things like deepcopy fraught with difficulty 
because the clear separation of concerns between parent and 
subclass has been broken.

It is very important for good OO design that classes only 
operate on their own data. But when you can dynamically 
add attributes to instances after theit creation, as you can 
in Python, it's almost impossible to distinguish between 
attributes of the parent class and the subclass. It's one of 
the penalties of Python's dynamic nature and there is no 
easy solution  to the general case. In the specific case 
you need to read the code of both parent and subclass 
and the application(s) using them!

> What if you give B a one-arg constructor by making the 
> bTag argument optional? Then I think B.__deepcopy__() 
> can call A.__deepcopy__(), then do the "B" part of the 
> copy on the result.

As a minimum subclasses should adhere to the parent interface.
Unfortunately because Python only allows a single constructor 
that can be a limiting factor :-(
( Multiple constructors (or factory methods) is one feature I 
  would like to see added to Python! )

Alan Gauld
Author of the Learn to Program web site

More information about the Tutor mailing list