Reasons Python Sucks (2018)

Some of the author&#x27;s &quot;reasons&quot; are bogus:<p>&quot;My code for Python 3.5 won&#x27;t work with the Python 3.7 installation unless I intentionally port it to 3.7.&quot;<p>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, ...<p>&quot;In Python, you have to work to pass variables by value.&quot;<p>No, you don&#x27;t. Python actually doesn&#x27;t pass variables &quot;by reference&quot;. It passes object pointers, but you can&#x27;t &quot;mutate&quot; an object pointer; it will always point to the same object forever.<p>What this author doesn&#x27;t seem to get is that in Python, &quot;variables&quot; aren&#x27;t labels for memory locations; they&#x27;re namespace bindings. And unless you explicitly use the global or nonlocal keyword, nothing you do with setting variables inside a function will affect the caller&#x27;s namespace. Which means that, in effect, Python variables <i>are</i> passed &quot;by value&quot; to functions--the function can only work with the object it was passed, it can&#x27;t mess with the namespace it was passed from.<p>What does often trip up new Python programmers is that if you pass a <i>mutable</i> object, like a list or a dict, to a function, the function <i>can</i> mutate the object (add items, remove items, change what object a key or an index refers to). But the claim the author is making is much broader than that.<p>&quot;Calling the same object by different names doesn&#x27;t change the object, so it is effectively global.&quot;<p>I think this person simply doesn&#x27;t understand how Python works.

&gt; an associative array is sometimes called a &#x27;hash&#x27; (Perl), but Python calls it a &#x27;dictionary&#x27;. Python seems to go out of it&#x27;s way to not use the common terms found throughout the computer and information science field.<p>The author isn’t well-informed. “Dictionary” is the original and traditional name for associative arrays in computer science. Smalltalk uses it as well, as do many CS books on algorithms and data structures. See for example: <a href="https:&#x2F;&#x2F;www.nist.gov&#x2F;dads&#x2F;HTML&#x2F;dictionary.html" rel="nofollow">https:&#x2F;&#x2F;www.nist.gov&#x2F;dads&#x2F;HTML&#x2F;dictionary.html</a>

Overopinionated engineers are annoying. Python doesn&#x27;t suck, everyone knows that. Every language has its strengths and weaknesses. Clickbaity.

&quot;Reason 7: Pass By Object Reference&quot;: isn&#x27;t this the case of almost every GC&#x27;d language? Java, JS, PHP, Swift, and C# all do so, although C# doesn&#x27;t if your type is a &quot;struct&quot; not a class. Go is the only popular exception I can think of.

Reason 2 seems to indicate that the author doesn’t understand how Linux distributions work either, in addition to Python.

Here&#x27;s a better list.<p>* Performance is very bad.<p>* Misspelling a variable creates a new one.<p>* __init__ is a really terrible name for the constructor.<p>* Type annotations are ignored, so nobody bothers.

I was actually interested to read a list of quirks, especially since I haven&#x27;t used Python in quite a while now and the author claims it has more quirks than any other language they&#x27;ve ever seen. And yet, the only example is the relatively easy to understand quoting. What is this article actually for?

I haven’t had skin in the game for years, so my opinion isn’t super valuable here.<p>Anyway, some of this is valid, albeit a lot of that is either well trodden (eg py3 gripes, pros&#x2F;cons of significant whitespace) or host environment&#x2F;tooling specific (eg where a thing installs `python` and which version without additional qualification and whether that’s stable).<p>But some of this is <i>surprisingly</i> mind boggling! I interrupted my reading of it somewhere in the beginning of<p>&gt; Reason 7: Pass By Object Reference<p>The author spends quite a lot of time expressing familiarity with not just their preferred language C but demonstrating fairly intimate familiarity with <i>several</i> dynamic languages… several which have a reputation for exhibiting or even exacerbating exactly the same problem described. They even allude to some of that earlier. <i>Huh?</i><p>I’d already glossed over the possibility to rename imports gripe (I think most module systems support this? Certainly the ones which augment the local namespace without any mechanism for disambiguation do, otherwise good luck ever getting anything done!)<p>If author is here reading, I’m not posting this to pile on, but to express honest confusion about how you’ve selected these gripes and how they line up for you with the seemingly greener pastures referenced. I don’t even much like Python either! I’m just getting a lot of cognitive dissonance trying to understand the perspective.

This feels like it was written by someone who has been writing C code their entire life.

Much of this seem to be the gripes of an inexperienced python user (e.g. experienced users tend to work with environment managers like miniconda, which turn the version hell the author complains about into a downright strength, making python environments considerably easier to manage than C environments).<p>And the author mangles their Perl history as well. Perl 5 was (and is) by far the most popular version of the language. It was Perl 6 which started a decline, and that might have been due to an overambitious scope, a huge delay in releasing a production ready version, and an Osborne effect as much as much as due to incompatibilities.

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].<p>That being said, I really don&#x27;t think any of the reasons here get to why python isn&#x27;t fun to write large code bases in. I&#x27;d say my biggest pain point has more to do with it&#x27;s typing system (which is getting better).<p>[0] Can it be done properly? Sure. But I personally feel worse about python the more complex a library I&#x27;m writing gets.

I agree with the sentiment that these reasons are terrible.<p>My main gripes:<p>- the half hearted take on static types<p>- excessive use of mutability and imperative programming<p>- dependency, version management and compatibility.<p>For this last one. Are there recommended best practices? I noticed that pip recently added a “constraints” file option which seems like it’s going towards at least the lock file level of guarantees that node has. Or do people still recommend using a separate manager (conda&#x2F;miniconda).

That history of Perl part seems a bit off. Perl 5 was wildly popular, and most of the early web was a mix of Perl 4 and Perl 5. People left for various reasons, many of them stemming from Perl 6 always being delayed and lack of momentum in Perl 5, but definitely not because Perl 6 was here and people didn&#x27;t want to switch.<p>That&#x27;s not to defend Python versioning though, which as a sysadmin supporting devs is always a pain point.

This is seriously one of the dumbest things I&#x27;ve read in a while.<p>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&#x27;t make any sense today.<p>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.<p>The complaint about the syntas being unreadable is also bogus. &quot;You end up with your editor wrapping the long lines!&quot; - well, just use parentheses to wrap complex expressions and break them down on multiple lines, like I do in EVERY programming language.<p>&quot;Finding a list of what can be imported is not intuitive and people end up grepping the codebase&quot; - grepping header files in &#x2F;usr&#x2F;include is exactly what I&#x27;ve been doing for years in C&#x2F;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.<p>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.<p>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&#x27;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&#x27;t have to create a lots of copies of a value for different function calls unless you have to.<p>To be clear, I also criticize many of Python&#x27;s design choices. Starting with its functional features, which are either ugly afterthoughts or they don&#x27;t exist at all. I hate the idea of using list comprehension for everything, or having map&#x2F;filter&#x2F;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.

I just want to say, working with python in an air gapped environment is fucking painful too.<p>I am not working with it directly but indirectly with ansible, and one of the playbooks (or &quot;collections&quot; in the latest iterations of ansible) has a stupid requirement to perform a pip install some random packages. Maybe there is a way to compile those packages offline and tell pip to use a tar ball. But I couldn&#x27;t figure it out so I just commented out those specific steps. I even went so far as to grok the repo for any references to this package but couldn&#x27;t find anything.<p>On the other hand, I do appreciate python&#x27;s concise syntax and makes it easy to write a few powerful one liners.

I&#x27;ve just realized that in my previous comment I&#x27;ve barely touched the surface of what I would have expected from an article that criticizes Python.<p>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.<p>2. Criticism about the &quot;there should be one way (and preferably only one way) to do it&quot; 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 &quot;one way of doing things&quot; 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&#x27;ll easily hit readability walls. Iterating on multi-dimensional array means &quot;two or more nested loops in your list comprehension&quot;, 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 &quot;one way of doing things&quot; 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).<p>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&#x27;t see much point in it if it&#x27;s just about showing some warnings in your IDEs without actually enforcing the typing constraints - at least at runtime.

There are legitimate criticisms to be made of Python but this is a pretty poor list.

Discussed at the time:<p><i>Reasons Python Sucks</i> - <a href="https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=18706174" rel="nofollow">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=18706174</a> - Dec 2018 (535 comments)

Many of these things are annoying, but I wanna check something....<p>Lists in python are called lists because they&#x27;re linked lists right? They are not called arrays because they are a different data structure.<p>Edit: Well TIL! Thanks everyone.

Some of his complaints are best addressed by using an IDE. I use Pycharm.

Those aren&#x27;t reasons why python sucks, but these are.<p>* The standard library still sucks<p>* The documentation still sucks<p>* Dependency management still sucks (unless you cope with poetry).<p>* it doesn&#x27;t have CPAN<p>* It&#x27;s not a lisp

Tl&#x2F;dr: Author is under the misapprehension that &quot;I hate Python&quot; and &quot;Python sucks&quot; are the same thing.

Python is selfish ;)

Reason 0: eggs and wheels

Yeah, as much as I hate python (after 10 years of a career based solely in it), “There are only two kinds of languages: the ones people complain about and the ones nobody uses.”<p>Although if I made a list it probably wouldn&#x27;t match this one. Reason 1 and 2 are basically the same, and yeah this sucks and I wish I could just build a static binary like Go. I&#x27;m surprised more languages don&#x27;t make this very easy!<p>Reason 3, I can&#x27;t care about the whitespace debate anymore. But<p>&gt; Deep nesting is permitted, but lines can get so wide that they wrap lines in the text editor.<p>??? This article is 5 years old, and we have black now to solve this; but I&#x27;m pretty sure most production code bases have had hard line limits in the style guide.<p>Reason 4,<p>&gt; Finding a list of what can be imported is non-intuitive. With C, you can just look in &#x2F;usr&#x2F;include&#x2F;*.h. But with Python? It&#x27;s best to use &#x27;python -v&#x27; to list all of the places it looks, and then search every file in every directory and subdirectory from that list<p>I don&#x27;t think C&#x2F;C++ is actually that much better at this?<p>&gt; In contrast, many Python modules include initialization functions that run during the import.<p>They can but they commonly don&#x27;t. A lot of python is about &quot;we&#x27;re all adults here&quot;, and that works surprisingly well.<p>Reason 5<p>&gt; In every other language, arrays are called &#x27;arrays&#x27;. In Python, they are called &#x27;lists&#x27;.<p>I mean there&#x27;s a good reason for that, and I don&#x27;t think C++ would call that data structure an `array` either.<p>&gt; Python seems to go out of it&#x27;s way to not use the common terms found<p>Honestly CS loves to give +3 names to basic things all over, this isn&#x27;t new to python. I don&#x27;t think the author&#x27;s chosen ones are correct.<p>Reason 6, I think newer languages are doing similar things with strings that python did, so I&#x27;m gonna say the wider community things this was a decent thing to do. And I&#x27;m not sure triple quotes is as complicated as =&#x2F;==&#x2F;=== in JS.<p>Reason 7,<p>&gt; This means that changing the source variable may end up changing the value.<p>If you mutate an object I&#x27;m not surprised the change is propagated. But there are immutable values, notably strings, that will not work this way. I can&#x27;t say this author shows much experience with any language in depth.<p>Reason 8, I don&#x27;t think I&#x27;ve ever heard of someone complain about namespacing like this, and then compliment C.<p>These reasons all feel the like &quot;it&#x27;s not like the first language I used&quot; rather than real issues.<p>What about default mutable arguments? What about namespacing of loop variables (and other wild ass shadowing rules when you do nested functions)? What about tooling??? You haven’t lived until you’ve made pylint or MyPy crash. And when they work, they are slow! And MyPy can be unstable in results on large code bases!

Ayup. If you have these same points of view that the author does: <i>please don&#x27;t use Python</i>. There is no shortage of languages out there that would be a better match for you--please use one of those.<p>However, the packaging and installation thing is very valid--Python really sucks at that and needs to fix it.