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 ----- -- http://mail.python.org/mailman/listinfo/python-list
