[Tutor] subclass problem: __names and type-checking

[Brian van den Broek]

Python said unto the world upon 2005-10-08 12:32:

Thanks for the response, Llyod. (And to Alan, too.)

> I think that a sub-class *needs* to support the same programming
> interface as the parent class. 

<snip>

> If B inherits from A then every context where A or an A instance appears
> should work correctly with B or a B instance.  Since the B constructor
> *requires* more arguments, it violates that ideal.  In other words, it
> would be OK to allow additional arguments.  It is not OK to require
> them.

The code I posted was an abstracted example. What I actually have is a 
base class with 2 arguments with default values and the subclass 
having those 2 (different defaults) and two more, again with defaults. 
So, unless I misunderstand, what I have meets the ideal here.

> In other words sub-class should really be a different class that adapts
> or possibly acts as a proxy for the _BaseClass.  Obviously you have
> picked names that presuppose inheritance.
> 
> I've abused inheritance in the past in an attempt to reuse code and have
> usually regretted it.  


My actual context is a pretty central case of inheritance, I think. 
I'm making a Counter class will all sorts of bells and whistles that 
I've found myself deploying in other programs. Counter inherits from a 
sparse _Basic_Counter class. _Basic_Counter gives the common minimal 
interface I want, while not including the CPU-cycle consuming bells 
added in the subclass Counter.

I'm doing things like this because usually the cpu-cycles for the 
bells won't matter. But, with _Basic_Counter, for the cases where I do 
want something more efficient, the basic interface will remain the same.

So, I believe that your good advice was already being headed. Thanks, 
though!

Brian vdB