overriding methods - two questions

[George Sakkis]

On Nov 19, 7:44 am, Bruno Desthuilliers <bruno.
42.desthuilli... at wtf.websiteburo.oops.com> wrote:
> George Sakkis a écrit :
>
>
>
> > On Nov 16, 5:03 pm, Steven D'Aprano <st... at REMOVE-THIS-
> > cybersource.com.au> wrote:
>
> >> 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. Why do you
> >> want to stop them?
>
> > Primarily because of this:http://en.wikipedia.org/wiki/Liskov_substitution_principle.
>
> >> Let me give a practical example:
>
> >> (snip misleading example involving __init__)
>
> > Constructors are in general different from other regular methods
> > because you refer explicitly to the class name when creating an
> > instance;
>
> Not necessarily. There are (quite a few) cases where you don't know
> which "concrete" class you're instanciating...
>
> > that is, the client writes "f = ContinuedFraction(...)" or
> > "f = RegularCF(...)" so it's not necessary to have the same signature
> > in __init__.
>
> import platform
> cls = platform.get_the_class()
> obj = cls('yadda', 42)

That's why I qualified my statement with "in general" ;-) Besides,
this emphasizes even further the need for consistent (though not
necessarily identical) signatures in all (public) methods, which was
my point anyway.

George