Live data from Hacker News

Reasons Python Sucks (2018)

hackerfactor.com

61–70 of 74 posts

Re: Reasons Python Sucks (2018)

#61
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.

Re: Reasons Python Sucks (2018)

#62
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.

> it produced a deprecation warning for a few versions

Eight, to be exact: 3.3, 3.4, 3.5, 3.6, 3.7, 3.8, 3.9, 3.10. Python 3.3 was released more than 10 years ago. That's a long time for a feature to be deprecated before being removed altogether.

> your script that works in python 3.x is not guaranteed to work in 3.y

True, not "guaranteed" in every single respect. But spotting and fixing a deprecation warning is pretty simple. So are fixes for other examples of feature removals (and I don't think there are that many in Python 3). That's nothing like the picture the author was painting; he was talking as if code needs to be "ported" between each version, which is just nonsense.

Re: Reasons Python Sucks (2018)

#63
post #62

Earlier quoted context omitted.

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.

> it produced a deprecation warning for a few versions Eight, to be exact: 3.3, 3.4, 3.5, 3.6, 3.7, 3.8, 3.9, 3.10. Python 3.3 was released more than 10 years ago. That's a long time for a feature to be deprecated before being removed altogether. > your script that works in python 3.x is not guaranteed to work in 3.y True, not "guaranteed" in every single respect. But spotting and fixing a deprecation warning is pret…

3.0 or 4.0 is the time to drop a user-facing feature. If 3.11 is not backward compatible, they aren’t following semver. I won’t assume every minor version bump must break stuff, but I have to be aware that it might and budget time for fixes.

Re: Reasons Python Sucks (2018)

#64
post #62

Earlier quoted context omitted.

> it produced a deprecation warning for a few versions Eight, to be exact: 3.3, 3.4, 3.5, 3.6, 3.7, 3.8, 3.9, 3.10. Python 3.3 was released more than 10 years ago. That's a long time for a feature to be deprecated before being removed altogether. > your script that works in python 3.x is not guaranteed to work in 3.y True, not "guaranteed" in every single respect. But spotting and fixing a deprecation warning is pret…

3.0 or 4.0 is the time to drop a user-facing feature. If 3.11 is not backward compatible, they aren’t following semver. I won’t assume every minor version bump must break stuff, but I have to be aware that it might and budget time for fixes.

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

Re: Reasons Python Sucks (2018)

#65
post #64

Earlier quoted context omitted.

3.0 or 4.0 is the time to drop a user-facing feature. If 3.11 is not backward compatible, they aren’t following semver. I won’t assume every minor version bump must break stuff, but I have to be aware that it might and budget time for fixes.

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.

Re: Reasons Python Sucks (2018)

#66

As someone who writes Python 9 to 5, I much rather be writing Rust (which I do in my spare time) and would concur that Python generally sucks to write large code bases [0]. That being said, I really don't think any of the reasons here get to why python isn't fun to write large code bases in. I'd say my biggest pain point has more to do with it's typing system (which is getting better). [0] Can it be done properly? Su…

This is a flaw with many other languages. Static types save you a lot of headaches past a certain size.

Re: Reasons Python Sucks (2018)

#67
post #55
post #39

Earlier quoted context omitted.

> everyone knows that Uh, no. There’s a reason I prefer Node, Deno or Rust, and the reason is that Python sucks. Or at least sucks more than either of those.

This reflects more on you than the language: no language is perfect but if something is popular and successfully used for many projects, it’s unlikely that it reaches the level of “sucks”. It’s far more interesting to talk about what traits you like or don’t like because those are things which can be evaluated by readers who can mull how relevant your experience is to them. For example, if you say you’re working on e…

Python doesn’t suck in general, it just sucks by comparison.

The main benefit I hear people say Python brings are the libraries that are written in it, but that’s not really a property of the language itself.

Re: Reasons Python Sucks (2018)

#68

Here's a better list. * Performance is very bad. * Misspelling a variable creates a new one. * __init__ is a really terrible name for the constructor. * Type annotations are ignored, so nobody bothers.

You probably already know that __init__() isn’t a constructor, technically; it’s an initializer.

Re: Reasons Python Sucks (2018)

#69
post #67
post #55

Earlier quoted context omitted.

This reflects more on you than the language: no language is perfect but if something is popular and successfully used for many projects, it’s unlikely that it reaches the level of “sucks”. It’s far more interesting to talk about what traits you like or don’t like because those are things which can be evaluated by readers who can mull how relevant your experience is to them. For example, if you say you’re working on e…

Python doesn’t suck in general, it just sucks by comparison. The main benefit I hear people say Python brings are the libraries that are written in it, but that’s not really a property of the language itself.

By comparison, in context. Context really is everything here

Re: Reasons Python Sucks (2018)

#70
This is seriously one of the dumbest things I've read in a while.

The points the author makes about version incompatibility were already very weak in 2018, when the article was written and Python 2 had already been declared deprecated. They don't make any sense today.

The problem about incompatibility across minor version is nonsense. Yes, some new features introduced in a minor version are often not back-compatible with previous minor versions (like the walrus operator in 3.8, or typing annotations on variable declaration in 3.6), but the previously written code is ALWAYS forward-compatible to newer minor versions.

The complaint about the syntas being unreadable is also bogus. "You end up with your editor wrapping the long lines!" - well, just use parentheses to wrap complex expressions and break them down on multiple lines, like I do in EVERY programming language.

"Finding a list of what can be imported is not intuitive and people end up grepping the codebase" - grepping header files in /usr/include is exactly what I've been doing for years in C/C++. In Python you have sys.path telling you which paths are searched for modules - and, in most of the cases, if you used a virtual environment or system-installed modules, all the modules will be in the same folder anyway.

The complaint about 3rd-party libraries having inconsistent names (with Py at the beginning or end of the name) is also laughable nonsense. Take a look at the 3rd-party libraries built for Ruby, JS or PHP, and tell me where you find name consistency.

The complain about passing objects by reference is also nonsense. Java does it as well: if you pass a primitive value, then you pass it by value. If you pass an object, then you're passing a memory location by reference. It may seem unintuitive at first, but once you get used to it you really appreciate it, because you don't have to create a lots of copies of a value for different function calls unless you have to.

To be clear, I also criticize many of Python's design choices. Starting with its functional features, which are either ugly afterthoughts or they don't exist at all. I hate the idea of using list comprehension for everything, or having map/filter/reduce that either support one-liner lambda with an ugly syntax, or some cryptic getters defined in the operator module. And I was expecting to find this type of criticism in this article. Not the shallow rant of someone who has barely touched Python.

Post reply on HN