[Tutor] subclass problem: __names and type-checking
Brian van den Broek
broek at cc.umanitoba.ca
Sun Oct 9 23:09:05 CEST 2005
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.
> 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
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,
More information about the Tutor