Are the critiques in "All the things I hate about Python" valid?

[Chris Angelico]

On Sat, Feb 17, 2018 at 2:22 PM, boB Stepp <robertvstepp at gmail.com> wrote:
> This article is written by Nathan Murthy, a staff software engineer at
> Tesla.  The article is found at:
> https://medium.com/@natemurthy/all-the-things-i-hate-about-python-5c5ff5fda95e
>
> Apparently he chose his article title as "click bait".  Apparently he
> does not really hate Python (So he says.).  His leader paragraph is:
>
> "Python is viewed as a ubiquitous programming language; however, its
> design limits its potential as a reliable and high performance systems
> language. Unfortunately, not every developer is aware of its
> limitations."
>
> As I currently do not have the necessary technical knowledge to
> properly evaluate his claims, I thought I would ask those of you who
> do.  I have neither the knowledge or boB-hours to write a large
> distributed system code base, but I am curious if Python is truly
> limited for doing these in the ways he claims.
>
> BTW, I am not trying to start (another) heated, emotional thread.  You
> guys do sometimes get carried away!  I honestly just what to know the
> truth of the matters out of my continuing to learn Python.  I suspect
> there is probably some truth in his claims, but I am not sure if he is
> taking things out of their proper application contexts or not.

1) Type safety.

This is often touted as a necessity for industrial-grade software. It
isn't. There are many things that a type system, no matter how
sophisticated, cannot catch; for some reason, though, we don't hear
people saying "C is useless for industrial-grade software because it
doesn't have function contracts".

Anyway, if you want some system of type checking, you can use static
analysis (eg tools like MyPy) to go over your code the same way a
compiler might.

"The first glaring issue is that I have no guarantee that is_valid()
returns a bool type." -- huh? It's being used in a boolean context,
and it has a name that starts "is_". How much guarantee are you
looking for? *ANY* object can be used in an 'if', so it doesn't even
matter. This is a stupidly contrived criticism.

> Python markets itself as a dynamically-typed programming language,
> similar to Perl, Ruby, or JavaScript. The word “dynamically typed” has
> a positive connotation, more so than “weakly typed.” Conversely, the
> word “strongly typed” sounds more positive than saying “statically typed.”

Those are all different terms, and all of them are misunderstood.
They're not synonyms.

> Python ships with a threading module; but due to how the Python
> interpreter is implemented, it can only ever run one thread at a time.
> This is due to the infamous Global Interpreter Lock (GIL). In an age
> when the only computers around had a single core, this was
> nothing to fuss over.

Totally not true. The GIL does not stop other threads from running.
Also, Python has existed for multiple CPU systems pretty much since
its inception, I believe. (Summoning the D'Aprano for history lesson?)

> Python is relatively slow compared to programming languages that
> run closer to the operating system. The run time of the countdown
> example above is orders of magnitude faster when implemented
> in other language runtimes.

Yeah, it sometimes runs a bit slower in benchmarking. And it's way WAY
faster to code in. Case in point: I reimplemented an app in Python
based on a C# (one of the languages the article's author touts as
better than Python), and made a single file under a thousand lines
long out of what had been two separate projects (a UI and a library),
dozens of files, tens of thousands of lines, and tons of boilerplate
that looks like this:

https://github.com/geel9/SteamAuth/blob/master/SteamAuth/SteamGuardAccount.cs#L15

That's thirty lines of declarations to show how the JSON data
translates into this object's properties. In Python, I just decode
JSON to a dict, and then subscript that dict with whatever I need.
Zero lines of boilerplate.

So which one is more expensive? Hours and hours of programmer time, or
a few milliseconds of runtime?

> If you’re doing development on Mac or Ubuntu, you likely already
> have Python 2.7 installed (Windows normally does not come with
> Python pre-packaged). There’s a good chance that when you first
> started programming in Python, no one told you about this thing
> called Python 3 (no one told me at least).

Ubuntu ships with Python 3 installed these days (and they're working
on removing the need to have Python 2 installed). Macs ship with a lot
of outdated software, so the correct thing to do is to install the
latest anyway.

If "no one told you" about Python 3, you don't know how to ask. And
trust me, the Py2/Py3 gap is far less serious than the differences
between version X and version X+1 of many JavaScript libraries. I know
this for certain, having spent this past week resolving problems with
React and related package.

> Encapsulation and Packaging
> ...
> This is unsettling if you’re coming from a Java or C/C++ world and
> are expecting access modifiers. They simply do not exist in Python.

Yeah, it takes some getting used to. (Note that C doesn't have access
modifiers either, so it's really Java and C++.) Did you know, though,
that C++ is quite happy to let you cast a pointer to another type, and
then ignore all the access rules? Yeah, but that doesn't bother
people.

Ultimately, you can always break past those kinds of protections. So
why not put the protection into your source code instead of the
compiler? The leading-underscore convention makes it obvious any time
you "reach in" and manipulate private members. Sure, nothing stops you
from doing it. But that's why we read code, we don't just run it.

Yep, it's yet another hyperbole-filled article worded as click-bait.
Fortunately it does have some content in it, but most of it is the
same old complaints that have been known about - and solved - for
years.

ChrisA