<div class="gmail_quote">On Mon, Jun 1, 2009 at 2:27 AM, Alan Gauld <span dir="ltr">&lt;<a href="mailto:alan.gauld@btinternet.com">alan.gauld@btinternet.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">

<br>
&quot;Kent Johnson&quot; &lt;<a href="mailto:kent37@tds.net" target="_blank">kent37@tds.net</a>&gt; wrote <br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">
&gt; Yesterday, I posted a question to python-list involving custom<br>
&gt; deepcopies in an inheritance hierarchy. I haven&#39;t received any<br>
<br></div><div class="im">
ISTM that in general B.__deepcopy__() should call A.__deepcopy__() to do the &quot;A&quot; part of the work. In your example, this won&#39;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.<br>


</div></blockquote>
<br>
I&#39;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&#39;s explanation is much clearer!<br>
<br>
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<br>
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.<br>


<br>
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&#39;s almost impossible to distinguish between attributes of the parent class and the subclass. It&#39;s one of the penalties of Python&#39;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!<div class="im">

<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
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 &quot;B&quot; part of the copy on the result.<br>
</blockquote>
<br></div>
As a minimum subclasses should adhere to the parent interface.<br>
Unfortunately because Python only allows a single constructor that can be a limiting factor :-(<br>
( Multiple constructors (or factory methods) is one feature I  would like to see added to Python! )<br></blockquote></div><br>
<div>Wouldn&#39;t it be possible to create sort of a... bastardization? i.e.</div><div><br></div><div>def __init__(self, *args):</div><div>    if len(args) == 0:</div><div>        #do something</div><div>    if len(args) == 1:</div>

<div>       #do something else</div><div><br></div><div>etc.?</div><div><br></div><div>Or would that create more problems than is worth it?</div><div><br></div><div>-Wayne</div>