Python is not a great programming language

Yes. I have my disagreements with Python, but those are not it. The article author is mostly complaining about ways Python differs from Javascript.

- Agree that the mechanism for talking about parent classes wasn't very good. Multiple inheritance usually adds complication without adding much necessary functionality. That's not just a Python problem. It's a leftover from viewing objects through an "A is-a B" lens, one of the dead ends of early AI.

- Python has too much gratuitous dynamism. Any thread can find and mess with any code and data in another thread. The implementation has to support that, which knocks out many valuable optimizations. The language model, and the original implementation, use "everything is a dict", which implies "slow".

- One consequence of the above is Python's terrible one thread at a time thread system, with the "global interpreter lock". The "multiprocessing" hack to get around that is ugly and uses too much memory, since each subprocess has its very own Python system instance. To some extent, the "async" add on is yet another hack to get around the limits of threading.

- Another consequence is a tendency to call C code where Python performance is terrible. The C code has to carefully obey the rules of the Python system. Mostly it does.

- Optional typing is a marginal idea, but unchecked marginal typing is just weird. Language design seems to be converging on implicit static typing - result variables are automatically typed whenever possible. Go, Rust, and now C++ (with "auto") took that route.

- And, of course, the botched Python 2 to 3 transition set Python back for a decade.

On the other hand, Python exceptions work out well. A reasonably sane exception hierarchy helps. Although the one for 2.x was better than the one for 3.x; the 2.x one made a clear distinction between external problems ("Environment errors") and internal problems.

The "with" clause system plays well with exceptions, and nested exception failures unwind correctly. It's far better than Go's "defer". C++ and Rust try to handle this sort of thing with RAII, which never handles trouble in a destructor well.

    dic = {k: v for k, v in dic.items() if k in other_dic and v == "bar"}

If I'm understanding the comprehension correctly,

    (into {} (filter (fn [[k v]] (and (get other-dic k) (= v "bar"))) dic))

  (->> dic
       (filter (fn [[k v]]
                 (and (get other-dic k)
                      (= v "bar"))))
       (into {}))

I've been pleasantly surprised how shallow the "general python rabbit-hole" is.

If i can express this in words, one of the ways I like to judge a language when I program: i think of something a computer could theoretically do, then I look for ways to express it in that language. How many independent jumps I have to take down the conceptual rabbit-hole before I get to the solution is a nice little arbitrary metric.

Does python do everything the way I'd do it? No. You get over yourself and just accept that's the way it is in this language.

Once I've done that, so far most problems in python have been pretty shallow: do this arbitrary thing and then this arbitrary thing and you're done.

Compared to some of my past languages where you have to go 4 or 5 levels deep with N compulsory but conceptually irrelevant steps, it's pretty damn good. Makes for a reasonable quick pathway to actually getting anything done...

Purely my subjective opinion.

You're right here. Probably can't work like that since generators are too general, you can't expect them to be rewindable or to not have side effects... prob you'd need a more specialized concept like a "lazy list" that would be a subtype of generator with some extra restrictions that would make it possible to implement the "hybrid" structure as an implementation detail without changing semantics.

Anyway... it would be too much work and probably would turn into a footgun.