[Python-Dev] Confirming status of new modules in 3.4 (original) (raw)

Charles-François Natali cf.natali at gmail.com
Sun Mar 16 15:08:11 CET 2014

2014-03-15 21:44 GMT+00:00 Nikolaus Rath <Nikolaus at rath.org>:

Guido van Rossum <guido at python.org> writes: > This downside of using subclassing as an API should be well known by now > and widely warned against.

It wasn't known to me until now. Are these downsides described in some more detail somewhere?

The short version is: "inheritance breaks encapsulation".

As a trivial and stupid example, let's say you need a list object which counts the number of items inserted/removed (it's completely stupid, but that's not the point :-):

So you might do something like: """ class CountingList(list):

[...]

def append(self, e):
    self.inserted += 1
    return super().append(e)

def extend(self, l):
    self.inserted += len(l)
    return super().extend(l)

"""

Looks fine, it would probably work.

Now, it's actually very fragile: imagine what would happen if list.extend() was internally implemented by calling list.append() for each element: you'd end up counting each element twice (since the subclass append() method would be called).

And that's the problem: by deriving from a class, you become dependent of its implementation, even though you're using its public API. Which means that it could work with e.g. CPython but not Pypy, or break with a new version of Python.

Another related problem is, as Guido explained, that if you add a new method in the subclass, and the parent class gains a method with the same name in a new version, you're in trouble.

That's why advising inheritance as a silver bullet for code reuses is IMO one of the biggest mistakes in OOP, simply because although attractive, inheritance breaks encapsulation.

As a rule of thumb, you should only use inheritance within a module/package, or in other words only if you're in control of the implementation.

The alternative is to use "composition"

For more details, I highly encourage anyone interested in looking at the book "Effective Java" by Joshua Bloch (the example above is inspired by his book). Although Java-centric, it's packed with many advises, patterns and anti-patterns that are relevant to OOP and just programming in general (it's in my top-5 books).

cf -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.python.org/pipermail/python-dev/attachments/20140316/2fed1f12/attachment.html>

More information about the Python-Dev mailing list