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 _______________________________________________ Tutor maillist - Tutor@python.org http://mail.python.org/mailman/listinfo/tutor