[jcd at sdf.lonestar.org: Re: overriding methods - two questions]
J. Clifford Dyer
jcd at sdf.lonestar.org
Mon Nov 19 16:57:27 CET 2007
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.
----- End forwarded message -----
More information about the Python-list