All the things I hate about Python

These are the reason the author gives that "Python is a very problematic programming language for building reliable, high-performance distributed systems":

- Dynamic typing. (The author conflates strong/weak typing with static/dynamic typing. He claims Python is weakly typed. That is not correct. Python is strongly, but dynamically typed.)

- The GIL.

- Performance.

- Python 2 vs Python 3.

- No enforcement of private/protected/public class members.

- The Python packaging ecosystem.

There's nothing new in this post that hasn't been written about Python before.

Switching to C++, which has compile-time type checks, still won't help in the first example. The functions might, for example, raise an exception, or abort(), or do something else which isn't expressed in that type system. Or there might be a #macro which redefined the world out from underneath you. Or there may be templates.

There has to be some level of trust.

"I have no guarantee that is_valid() returns a bool type"

On the other hand, there's no need for that guarantee. All if requires is something which can be evaluated as true/false, including by defining a __bool__/__nonzero__ (Py3/Py2).

"I cannot, in the absence of perfect test coverage, verify the correctness of someone’s code is a big red flag."

I believe the author means "verify the type correctness" here. Formal verification is a much more complicated task.

"This is one of the reasons why compilers were invented"

I'm not sure I believe that. I don't think the original FORTRAN compilers even supported type checking in the way the author envisions.

"SyntaxError: invalid syntax"

FWIW, the indentations are wrong. I wonder if that's a Medium thing. Looking at the HTML, it looks awful - all on one line. Probably stripped of extra whitespace to save bytes, and accidentally removing the extra whitespace in the pre.

"Typically only package-wide definitions should go in that file. Core logic should not be placed in these __init__.py files."

Really? You know, I have no idea about how typical that is. Some of the standard library packages do not follow that advice. For example, "venv/__init__.py" contains the logic, while __main__.py is available for "python -mvenv", and there's a scripts/ subdirectory containing scripts for different shells.

I agree that "import numpy" is horrid. It's designed for people who type "python" (or alternative like Jupyter) and sit at the interactive shell all the time. It's not meant for people like me who might want one function to use in a script which gets called often.

As a result, the "import numpy" also imports numpy.the.kitchen.sink so that some scientist somewhere doesn't have to do "import numpy.the.kitchen" before doing numpy.the.kitchen.sink.

I have several times rewritten or extracted the code I want from NumPy so I can avoid all the garbage it does at startup.

(Yes, I have strong feelings about this.)