Where’s the literature on object-oriented programming with Python?

Articles
Author

Fábio P. Fortkamp

Published

July 1, 2024

When I started my current job, I took over the development of a wellbore simulator written in Python. I don’t know exactly the reasons why the previous maintainer chose this language, but I can imagine: at least in engineering academia, Python is the new MATLAB, used as synonym for “numerical computation”, with many good libraries for data science, linear algebra, machine learning, visualization and so on. The previous developer did the hell of a job building a robust program, relatively fast in simulating a petroleum production operation, using a high-level programming language.

Here’s my problem: the program is, or attempts to be, very object-oriented. This makes perfect sense, since simulation software begs for classes: you have a Fluid to which you can request the calculation of properties, a Solver that allows you to run it, a Writer that generates reports and so on. Python has support for classes, inheritance, polymorphism and the like. And yet, when I read books about object-oriented programming, all I see is code in Java and C#. And I see books about Python, they only use snippets of code, isolated functions, and showcases of cool language features such as list comprehensions - either implicitly or sometimes explicitly advocating “running the code in a Jupyter notebook”.

Where is the literature in developing professional, production-ready, object-oriented programs using Python?

When questioning myself about this, I oscillate between two explanations:

  1. No writers: there’s no publisher’s interest, since all Python books must be targeted at data science or machine learning to enjoy the current AI moment;
  2. No readers: there’s no market, since software like ours is actually written in compiled languages, and we are the outsiders. The Mikado Method, for instance, talks about dynamic languages in the context of developing a large program in an appendix.

In any case, this is one more argument for me to preach polyglot programming - if you develop software of any kind, either as your main job or as part of your job as a scientist, engineer, research and the like, you cannot restrict yourself to one programming language. Languages are tools, and the more tools you can use, the better.

There’s still difficulty translating concepts between langauges. One book that I’m studying currently after buying it in a bundle is Five Lines of Code. I’ll have my review of it in a while, but before that let’s talk about one construct the author Christian Clausen talks a lot about: interfaces, or contracts for classes. Clausen uses a full game written in TypeScript (no random snippets), with classes, methods, functions etc, and adovates the use of interfaces to make the program clear.

Python has no interfaces.

Well, it has abstract base classes, which are similar but not the same; this is used by type checkers, and not during runtime. Luciano Ramalho goes as far as saying it in Fluent Python that they are for framework developers. If I’m the solo developer of an app and, while trying to understand what a Liquid and Gas have in common in the context of my program, I write an ABC for that situation, am I wrong? Am I “over-engineering”?

In the end, this is what I do: I learned Java almost 15 years ago when everything I wanted to do was to take programming classes online. For me, knowing Java is basic programming literacy, since so many books are written in it, and it helped me a lot in my PhD work because COMSOL thankfully had a Java API. With that knowledge, I study regularly the bibliography of Uncle Bob (this latter book is written in C#, which has virtually identical syntax as Java), and dig around to see how to do it in Python. The afore-mentioned Fluent Python is the bible of Pythonic code.

Oh: and for interfaces, I just create a class with I in the front of the name, 2000s-style, and become in peace with it.