
All the things I hate about Python - BerislavLopac
https://medium.com/@natemurthy/all-the-things-i-hate-about-python-5c5ff5fda95e
======
js2
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.

------
eesmith
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.)

