Skip to content

A Note on Python

Tuesday, 7 January 2025  |  Frans Englich

The advantages of Python are well known and it is a language that still remains hyped — but let’s look at some of its other sides.

Line Count

One positive side of many solutions is by stressing how few lines something requires. That’s especially the case with Python, but it doesn’t take into account the whole Software Development Life Cycle (SDLC).

One does not only want to churn out some idiomatic example code. Instead one has a large, complex software project that needs to be robust and withheld quality assurance during a long product lifetime. Hence one looks after other qualities other than whether the very initial effort requires little code.

Contracts Matter

Python’s typing system is so-called duck typing: ”If it walks like a duck and it quacks like a duck, then it must be a duck”. First of all, it means that if a caller doesn’t live up to the contract of the API, it will result in an obscure crash somewhere far down in the called code. The caller have to figure out what went wrong. This is a problem because in QA there’s the mantra that exhaustive testing is impossible, which is one reason to why we have to rely on code robustness.

I also think types is natural documentation. “What does this function do? What does it expect?” Types document that. Hence I argue conceptually for abstract base types such as Swift’s protocols, Java’s interfaces and so forth.

Versus MatLab

I replace MatLab with Python for quantitative finance, but what I miss in commercially backed projects such as first-mentioned, is good documentation. For instance NumPy and Pandas lack a consumer/user/customer-centric perspective, as opposed to what perhaps (we) programmers enjoy to do. For some reason open-source perhaps doesn’t attract for writing documentation. While it could make use of systematic addressing of this problem, it is low hanging fruit for Google Summer of Code, for instance.

Python is slow and I see the solution in the computation area as a hack: the code path jumps into C/C++ land using NumPy and Pandas. This is fine, but the code becomes convoluted and I associate to Perl’s “write once, understand never.” It feels like Python attempts to be taken to an area which results in an ill design.

Conclusion

What is Python useful for? I believe light, small tasks, such as doing something computationally advanced that isn’t a complex software project. The lack of typing means you cannot (or perhaps shouldn’t) write large applications, and perhaps performance is relevant.

However, for the more short computation and script tasks it is excellent, and it is indeed in that area it receives publicity.