Pythonicity: Composition vs. Inheritance | Hacker News Reader

Pythonicity: Composition vs. Inheritance

coady.github.io

29 pointsPaulHoule11 comments

Having had the great pleasure of refactoring a few python libraries, I've had to encouraged people to switch away from inheritance.

You often get a ton of methods / attributes on the child class, which gets hard to keep tabs on. You have to be careful not to use the same names for things. (The worst is that someone uses this broken encapsulation and relies on things across parent classes via the child).

I get that inheritance can go okay for simple cases, but have seen enough chaotic uses of it that I'd just encourage people to write the boilerplate for forwarding methods.

Yup. You're trying to debug something, and you're deep in ParentClass.some_method. some_method is pretty complex, so it's tough going, but each time it calls self.other_method() or self.yet_another_method(), is that call going to the methods of ParentClass or some sub class? And 15 minutes in, do you even remember whether it was SubClass or OtherSubclass?

Inheritance turns the functional structure of your code into mud. Unless inheritance is absolutely the best design, better to drop it.

Wouldn't this be solved by using private names in the parent class? No one overwrites class.__this__ without knowing that it's a deviation. To me that tabs are kept on just by using the double pair of underscores...

This seems like a shortcut to type less at the cost of very leaky encapsulation, which I don't think is a good trade. You may or may not want to expose all of jnettool.tools.elements.NetworkElement as a new interface, but choosing inheritance will always force you to expose everything from the inherited class. Furthermore, if you're extending classes that were not explicitly designed to be extended, this is fragile as there is no contract between your subclass and the base class and an implementation change in the base class may break you in unexpected ways.

What I also don't understand is how you're supposed to instantiate the new NetworkElement from an existing jnettool.tools.elements.NetworkElement. With delegation it's easy (just construct a wrapper with the object to be wrapped), but if the library is giving you instances of jnettool.tools.elements.NetworkElement, how do you get instances of your own subclass instead?

In TXR Lisp, you can delegate with struct clause macros :delegate and :mass-delegate:

https://www.nongnu.org/txr/txr-manpage.html#N-92252A14

https://www.nongnu.org/txr/txr-manpage.html#N-5F56EB59

These are themselves written via define-struct-clause, which provides a macro mechanism for writing new kinds of clauses that can appear in a defstruct:

https://www.nongnu.org/txr/txr-manpage.html#N-91BFF63B

define-struct-clause itself provides a kind of alternative to manually doing composition and inheritance: you just define some new clauses to do whatever is necessary and use them in the target classes.

A custom clause can cause the target class to inherit bases. What makes that possible is that inheritance is not only expressed using (defstruct duck (animal ...)) but alternatively via a an (:inherit ...) clause. Thus clause macros can generate (:inherit ...), thereby injecting bases.

> So a better question might be which version is more flexible or reusable?

In fact, inheritance has nothing to do with reusability (or flexibility): it's point is to provide typing hierarchy, so the code can follow the Liskov substitution principle.

In "traditional" Python, which is dynamically typed and never statically analysed, there were no built-in controls over what is being passed at runtime, so the only real purpose for inheritance was to reuse code. This changeds with the introduction of typing annotations -- while the runtime is still fully dynamic, you can use mypy and other static analysis tools to minimise type-related errors before deploying.

In fact, Python has a great way to both support composition and support interfaces without requiring inheritance: a combination of typing.Protocol and mixins.

I don’t necessarily disagree with the author that the “prefer composition over inheritance” advice is taken too far, but I don’t find this example to be too persuasive. Most of the simplification comes from using a list and named triple instead of new classes. Those are good techniques, but they aren’t inheritance. (Well, data classes tend to be better, but named tuples are perfectly fine here.)

> Python has no mechanism for embedding or forwarding methods

Scala 3 has export statements (https://docs.scala-lang.org/scala3/reference/other-new-featu...). I wish more OOP languages had something similar, so that there was less boilerplate when composing other objects.

And it is possible to implement something like that in python as a library, although a with a quick search I only found a couple of blog posts on how to implement something yourself.

Forwarding itself is trivial, just ~5 lines in __getattr__. The difficulty comes when you need to type check the thing. Fixing that would require some special treatment on the type system side and not really doable with a third party library.

It's a little more complicated than that if you want to forward some, but not all methods to the delegated object, or have multiple objects you want to delegate to. If you just have __getattr__ delegate everything to one other objects, there isn't much benefit over inheritance.

or just go with functions + unions/dataclasses

Reply on news.ycombinator.com