Live data from Hacker News

Reasons Python Sucks (2018)

hackerfactor.com

71–74 of 74 posts

Re: Reasons Python Sucks (2018)

#71
I've just realized that in my previous comment I've barely touched the surface of what I would have expected from an article that criticizes Python.

1. Criticism about performance. Such criticism would have held in 2018, but it holds much less nowadays, with Python 3.11 coming with tons of performance improvements, and tons of C-native libraries like numpy that can help you move numbers at the speed of light.

2. Criticism about the "there should be one way (and preferably only one way) to do it" approach. While this has helped keep the language very intuitive and the syntax very clear (in opposition to Perl), it has also put it on the wrong side of history when it comes to functional patterns. Quite ironically, the language is very popular among scientists and mathematicians, two categories that have always praised functional languages and patterns. The "one way of doing things" approach means that Python has fallen behind when it comes to functional patterns. Yes, list comprehension is very elegant for small things, but try to traverse a multi-dimensional array of objects using list comprehension, and you'll easily hit readability walls. Iterating on multi-dimensional array means "two or more nested loops in your list comprehension", which is a very unintuitive and imperative-like way of building algorithms. The functional way of doing things is through composition, and Python is a very weak language when it comes to composition. The lambda feature is also quite ridiculous - an ugly syntax that only supports one-liners, and it makes the code overall much less readable than having functions that can always be expressed in the same consistent way no matter the context (and that is a grave contradiction of the "one way of doing things" principle). Languages like JS solved the functional problem in a better way, and Kotlin does so in a much more elegant way. Python initially snubbed these patterns, then it came up with patches as an afterthought (like the functools and operator modules).

3. Oh, and typing. Static typing is another thing that came too much as an afterthought. I eventually like the typing implementation, but I don't see much point in it if it's just about showing some warnings in your IDEs without actually enforcing the typing constraints - at least at runtime.

Re: Reasons Python Sucks (2018)

#72
post #22

Some of the author's "reasons" are bogus: "My code for Python 3.5 won't work with the Python 3.7 installation unless I intentionally port it to 3.7." Sure it will, just invoke it using the Python 3.7 interpreter. I have plenty of code originally written with 3.5 that runs just fine under 3.7, 3.8, 3.9, ... "In Python, you have to work to pass variables by value." No, you don't. Python actually doesn't pass variables…

Recent counter example: if you have python code that uses the "U" open mode (e.g. open(file, "rU")), it doesn't work anymore with 3.11. Yes, it produced a deprecation warning for a few versions, but no, your script that works in python 3.x is not guaranteed to work in 3.y. There are plenty of other examples.

That's a decade to make a 30 second change. Add something like https://github.com/asottile/pyupgrade to your pre-commit hooks and you won't even need 25 of those seconds.

Re: Reasons Python Sucks (2018)

#73
post #64

Earlier quoted context omitted.

Does Python claim to follow semver? If not then I'm not sure what your point is.

From https://peps.python.org/pep-0006/ it seems that 3.10.9 is expected to be compatible with 3.10.8, but users need to treat 3.11.0 like a potentially major rather than minor release. I wish they had labeled it 311.0 to communicate this and set expectations.

PEP 006 describes the way Python versioning has worked since Python was first released. Yes, it's technically not quite the same as current semver, but current semver didn't exist anyway back then.
Post reply on HN