overriding methods - two questions

[Steven D'Aprano]

Thanks, I'm pretty damn unorganized in that way. Is it convention to do:

class BigLetterAndCamels():
def smallLetterAndCamels()

or
def smallletterandnocamels()

?

See the PEP and Guido's essay for recommended conventions:

http://www.python.org/dev/peps/pep-0008/
http://www.python.org/doc/essays/styleguide.html

 

[Steven D'Aprano]

Primarily because of this:
http://en.wikipedia.org/wiki/Liskov_substitution_principle.

"In object-oriented programming, the Liskov substitution principle is a
PARTICULAR definition of subtype..." [emphasis added]

There are other definitions possible. Also be careful of confusing
subclasses with subtypes:

http://en.wikipedia.org/wiki/Subtype
http://en.wikipedia.org/wiki/Subclass_(computer_science)

Python doesn't have types in the sense of the Liskov substitution
principle, because Python's subclass relationship need not imply
substitutability. In fact, the requirement for substitutability is quite
restrictive. (Whether it is a good thing or a bad thing is open for
debate.)

With duck typing and/or delegation, one might create a new class which is
substitutable for the original class, without it being a subclass. And
contrariwise, one might create a subclass which isn't substitutable for
the original class. Inheritance is a *mechanism* for getting identical or
similar behaviour without the anti-pattern of copy-and-paste programming
(code duplication). There's no logical requirement that two objects with
identical behaviour in one aspect must necessarily be substitutable for
each other:

chicken.lay_egg()
shark.lay_egg() # some sharks lay eggs


I don't see this as a bad thing (unless of course they are *supposed* to
be substitutable, in which case the failure to be so is a bug).

 

[Bruno Desthuilliers]

Steven D'Aprano a écrit :

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.

 

[Bruno Desthuilliers]

George Sakkis a écrit :

Primarily because of this: http://en.wikipedia.org/wiki/Liskov_substitution_principle.


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)

 

[J. Clifford Dyer]

Steven D'Aprano a ?crit :

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? I'm uncertain here, but I'm not persuaded that changing signature is bad.

 

[George Sakkis]

George Sakkis a écrit :






Not necessarily. There are (quite a few) cases where you don't know
which "concrete" class you're instanciating...


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

 

[Bruno Desthuilliers]

J. Clifford Dyer a écrit :

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.

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.