[jcd at sdf.lonestar.org: Re: overriding methods - two questions]

[J. Clifford Dyer]

On Mon, Nov 19, 2007 at 04:33:39PM +0100, Bruno Desthuilliers wrote regarding Re: overriding methods - two questions:
> 
> J. Clifford Dyer a ?crit :
> > On Mon, Nov 19, 2007 at 01:41:46PM +0100, Bruno Desthuilliers wrote regarding Re: overriding methods - two questions:
> >> Steven D'Aprano a ?crit :
> >>> On Fri, 16 Nov 2007 18:28:59 +0100, Bruno Desthuilliers wrote:
> >>>
> >>>>> Question 1:
> >>>>>
> >>>>> Given that the user of the API can choose to override foo() or not, how
> >>>>> can I control the signature that they use?
> >>>> While technically possible (using inspect.getargspec), trying to make
> >>>> your code idiot-proof is a lost fight and a pure waste of time.
> >>>
> >>> Worse: it's actually counter-productive!
> >>>
> >>> The whole idea of being able to subclass a class means that the user 
> >>> should be able to override foo() *including* the signature. 
> >> If you see subclassing as subtyping, the signatures should always stay 
> >> fully compatibles.
> >>
> > 
> > Isn't that more what Zope-type interfaces are for than inheritance?
> 
> With dynamically typed languages like Python, you don't need any formal 
> mechanism (zope-like interface or whatever) for subtyping to work - just 
> make sure your two classes have the same public interface and it's ok. 
> So indeed inheritance is first a code-reuse feature.
> 

Makes sense.  As nifty as interfaces seem, there's also something that struck me as too club-like about them.  Your suggestion seems much more pythonically dynamic and ducky.

> > I'm uncertain here, but I'm not persuaded that changing signature is
> > bad.
> 
> Depends if the subclass is supposed to be a proper subtype (according to 
> LSP) too.

Also makes sense, somewhat, but I'll need to reread the previously linked article, because I'm not clear in my mind on what makes a subclass a subtype *other than* having a matching signature.

Thanks,
Cliff

----- End forwarded message -----