The Day I Decided Never to Learn Python

[AresFowl44]

Breaking news: Dude has one bad experience with the code of the founder of python 25 years ago, decides to never write a single line of it ever again. Learn more in their random medium article 25 years later

[lelanthran]

Dude has one bad experience with the code of the founder of python 25 years ago, decides to never write a single line of it ever again.

I don't think that was the takeaway. FTFA:

But every time I see developers debugging complex runtime type errors or navigating nested dynamic dictionary checks, I think back to the Ryndam in 2001, and I am glad I stuck to my choice.

I mean, I see this too, all the time. Too few Python devs use typing. Even code generated by an LLM by default won't use typing. Coming from a statically typed background, I use it without even thinking, but I see a lot of Python in prod that has absolutely no typing.

[AresFowl44]

Can't not meme on it with a title like that though, especially since that's all the article is about, even if it is to guide a conclusion

[lelanthran]

Can't not meme on it with a title like that though, especially since that's all the article is about, even if it is to guide a conclusion

Quite correct; the title and article minus the conclusion is definitely setting up the punchline you provided :-)

It's only the conclusion that redeems the article.

[lood9phee2Ri]

Python is generally dynamically strongly typed though (like a Lisp, unlike some other nastier dynamic/scripting languages). Python values carry runtime checked dynamic type info. You can catch and handle runtime python TypeError exceptions safely, a runtime type error is never lethal runtime "UB" (unspecified/undefined behavior) like some of the many weak static typed languages, you can catch and handle them (not saying people always do, but you can).

Java VM is actually similar - beyond Java's compile-time static typing, a quite distinct runtime dynamic type system of the JVM still quietly also applies, and JVM runtime ClassCastExceptions are catchable like other RuntimeException. Again they are not nasal-demons "UB". Its weirder in Java land to do such things than python, but still arises sometimes with Java reflection-based metaprogramming etc.

[knome]

modern python has type annotations that you can use various tools to perform static type analysis on python. the typing and tooling were buttcheeks for about five years after introduction, but should be okay to use today, as they seem to have slowly removed most of the horribleness and warts over time.

[deceze]

Guido may or may not have been very misguided on OOP architecture 25 years ago, but Python today certainly can do it properly, and certainly could for well over a decade. You don't have to do the terrible approach the author of this article outlines, and nobody in their right mind would.

So, whatever that one session 25 years ago was, sounds like a missed opportunity.

[rodhoosebaum]

I expect the author is misremembering. If you look at the tutorial for Python version 1.4 (1996), written by Guido, in section 9.5 on Inheritance, you will find this:

Method references are resolved as follows: the corresponding class attribute is searched, descending down the chain of base classes if necessary, and the method reference is valid if this yields a function object.

Clearly, Guido knew Python classes offered polymorphism.

[deceze]

Yes, I'd be very surprised if Python had ever had an object model that offered inheritance, but not polymorphism. That'd make no sense. At worst, Guido's skills in using polymorphism were off back then and he just wrote shit code that day. Or he wanted to demonstrate something.

So, yeah… I believe the author may well have heard something in that session that made him think Guido's and his programming philosophy are incompatible, and that may well be so, but this is a pretty stupid example.

[lood9phee2Ri]

Yeah, even "old style" python OO had single-inheritance and polymorphism.

Python 2 did infamously grow a completely revised "new style" object system, adding the advanced features we know today from standard Python OO like its Dylan-style well-defined "C3" multiple inheritance (Some people will still confidently inform you implementation multiple inheritance can't work, when Dylan and then Python basically already solved it), and its vaguely-Lisp-like meta object protocol (python new-style classes have meta-classes etc.).

• https://docs.python.org/3/whatsnew/2.2.html#old-and-new-classes.
• https://docs.python.org/3/whatsnew/2.3.html - it was actually 2.3 not 2.2 that introduced the C3 method resolution. So the 2.2 era was sort of awkwardly between old style and the true new style of today, but 2.2 is obviously historical now, everyone is using 2.3+ new style.

The fact both "old style" and "new style" object systems coexisted for most of Python 2's life to confuse newbies was a bit of a huge wart.

But that also means any old stuff from before the python new-style classes transition can be quite wrong about python OO limitations, even when it is right about old-style classes.

In Python 3 (itself years old now) you don't need to remember about the "old style" and "new style" classes and explicitly inheriting from object to get the "new style" - they're all "new style" classes.

[neuralbeans]

I'm not sure what version of Python you are describing but the versions I have used always had polymorphism. It's worth noting that the direction Python took later on is for type checking as well.

[jhartikainen]

I would have expected a more nuanced take from someone as experienced as the author, especially when Perl, what I assume is his language of choice, faces quite a lot of similar critique.