Live data from Hacker News

Reasons Python Sucks

hackerfactor.com

321–330 of 554 posts

Re: Reasons Python Sucks

#321
I can't believe this was upvoted. These aren't reasons that Python sucks, they're nitpicks from a guy who has decided long ago that he knows what he likes and refuses to try anything else.

> "If I have the choice between using some pre-existing Python code or rewriting it in C, I'd rather rewrite it in C."

I should have stopped reading there, because this shows just how set the author is in his ways. Both languages have a place, and if I'm writing a web scraper, you can bet your ass it's not going to be in C.

Re: Reasons Python Sucks

#322

Earlier quoted context omitted.

> This begs the question though why can't the python ecosystem simply evolve? Is that too much to ask? It evolves constantly. Python packaging then and now has massively changed (largely without breaking compatibility, mind you). It's not perfect, but it is much better than it was in 2005.

On that note, I wonder why no one has tried to do packaging right, like really right, and then make it avaialble as a system for multiple languages. Someone should get on that. And I don't mean yum/apt/etc I mean like a universal package format for programming language packages with all the best bells and whistles, so fledgling languages can have a mature package system at their inception by simply linking with a C A…

Conda which was built for Python (Linux, Windows, OSX, arm) handles package dependencies. Anaconda is built on it and R packages are also distributed with it. If you really want to, you can build perl packages or really any kind of package you want.

Re: Reasons Python Sucks

#323
post #34
post #6

Many of the reasons authors states are quite silly. Personally I don’t like the huge perf hits everywhere you look. For example, a bool in Python takes whopping 24 bytes! Multi threading is a giant mess due to GIL that apparently no one can get rid of. Things like true static variables are missing. Import behavior differences for programs and modules is baffling. Lambda is intentionally kept under powered (ex. no gro…

Now this is a good list of things to hate about Python. I would add the fracturing of build methods for large applications is another frustrating thing about working with python. Although projects like Pipenv and Poetry seem to be bringing python up to modern standards in that arena.

I have yet to use poetry although I’ve heard great things and I’ve read a blog post that kind of sold me into it. How would you say it ranks compared to pipenv? I’ve had frustrating issues with the latter in the past month.

I can’t help but think that the lack of Kenneth Ritz in the commit list since summer has something to do with this. I don’t recall the exact scenario, but I think there was some kind of falling out between him and the community.

Re: Reasons Python Sucks

#324

Earlier quoted context omitted.

This begs the question though why can't the python ecosystem simply evolve? Is that too much to ask? You say these languages have learned so much from Python. If there is so much to learn in terms of do's and dont's, why doesn't Python simply follow this advice?

To a significant extent, it has. The article assumes you will use distro packages for the language, and pip for installing libraries. And that used to be standard practice. Today, if you are interested in a reproducible build environment, you will use pyenv to locally install an interpreter and stdlib, and pipenv to locally (to your project) install libraries and dependencies.

I would argue that for most projects (for most of my projects, anyway), this is still a sensible default. Except you should probably still be using distro packages for major libraries too.

Consider; the reason for installing dependencies locally to your project is that it allows you to be precise about what library version you want. For example in Rust, we have Cargo.toml and I can have dependencies like primal = "0.2". I hate this model. It takes us right back to the old days of projects shipping whatever version of a library they want and never updating it. For small projects this is a constant source of security issues and code stagnation.

I groan internally every time I see a project I'm interested in is written in node. Not because I dislike the language, but because I know when I download and build it there are going to be a dozen outdated dependencies hardcoded in the config file, some with "severe" security warnings flagged by npm.

I advocate letting library developers and distribution maintainers do their jobs. Most of the time new versions of libraries are supposed to be backwards compatible. When they're not the distribution can ship multiple versions of a library and make sure they all have security updates backported.

There are cases where managing all your own dependencies is important (like closed source web applications), but I think those are exceptions. Dependencies were supposed to be a solved problem.

Re: Reasons Python Sucks

#325
post #183
post #119

Earlier quoted context omitted.

> 1 (versions) and 2 (installation) have to do with the ecosystem, not the language. This argument really summarizes a beautiful and dangerous thing we see in the tech community far too often; you have a strong technical and scientific understanding of the system, but lack product and design thinking. You're right. Its a problem with the ecosystem, not the language. I'm still not going to use python because of the ec…

Note how almost all languages you take as shiny examples of virtue post-date Python: they all learnt from it so much , particularly on things like the stdlib. Python’s stdlib was the gold standard for a long, long time (the “batteries included” slogan was effective for a reason - they really were!). This was not by accident - Guido and others have always had the utmost care for good developer experience out of the bo…

It always surprises me when new languages don't make a REPL a top priority. It's such a crucial thing for a good developer experience. Rust still doesn't have one, as far as I know, and it's a major pain point for me as a light user of the language.

Re: Reasons Python Sucks

#326

Earlier quoted context omitted.

It's a two space error in a trivial example that no editor can help with . If the function is longer or their are a couple of additional levels of indentation, and it isn't a print statement, but some additional logic, it is a hard problem to spot.

Not true, look up indentation guides and whitespace visibility. Even my barebones editor has them and squashes ambiguity. Still at some point one needs to be responsible for the code they write, braces or not. Braces are not a guaranteed solution either, if the author gives up complete responsibility. Basically, this is a theoretical non-problem. The lack of braces pays back in readability every single day. Like +100…

I write python all the time, with editors that support this. People do encounter this problem.

You'll also note that I've never claimed braces were better, I'm just trying to explain OP's pont.

You may not encounter it, but "Hey it works for me" is not a legitimate answer.

Re: Reasons Python Sucks

#327
post #296

Earlier quoted context omitted.

> Python variables aren't names for storage locations to begin with; they're namespace bindings. Can you explain the difference? What is a "namespace binding"? When accessing a variable's value, the interpreter's code sure looks like it treats the variable name as the name of a storage location. > Passing a variable to a function means passing a particular namespace binding "Passing a variable to a function" is not a…

Here are pictures that explain the difference between variables as named boxes and names in Python https://david.goodger.org/projects/pycon/2007/idiomatic/hand...

That's a nice explanation for BASIC programmers, but for anyone who has ever programmed in some other programming language than BASIC, it should not come as a surprise that named boxes can store pointer values. As they do in Python. They literally store C pointers of type (PyObject *).

Re: Reasons Python Sucks

#328

Earlier quoted context omitted.

That one dumbfounded me as well. Has the author never given a pointer as an argument to a function before? Do they make copies of their strings and structs every time they want to pass it around? I just... I just don't understand how they could think that.

I think I can answer this one because it is one of my gripes of Python. The problem isn't that it doesn't copy, rather it is that the = assignment operator specifically doesn't copy. If you create a list "list1", set "list2 = list1", and change list1, both of the lists change. When I learned Python, this was a major source of confusion for me. Eventually I learned that in Python, instead of nothing being a pointer as…

I don't remember when in my Python career I learned about names vs. values, but it finally clicked for me that I'm predominately just binding a value to a name with the = assignment. Now everything I read has become very easy to reason about and understand.

Ned Batchelder is a good resource for learning many things about python, and this talk he gave at Pycon some years ago is no exception:

https://nedbatchelder.com/text/names1.html

Re: Reasons Python Sucks

#329
My take on this is that it has some valid points, but is mostly unjustified rants:

1. Versions: Definitely an issue with Python, the v2 to v3 split was a huge mess and is Python's biggest issue IMO.

2. Installation: Pros and cons, what I find is that Python tends to be easy to set up, but that it does it automagically for you via pip, which means if you run into trouble it is harder than doing it manually

3. Syntax: Python's syntax is wonderful and I find these arguments mostly flawed. The space vs tabs wars are the exception and a valid criticism that the language doesn't force one or the other. As someone on the tab side, I don't run into his issue at all of accidentally putting 3 spaces instead of 4 in, but then I do run the issue of going against the language's grain so to speak.

On the other hand, his issue about deep nesting is a problem in any programming language - unless he is not indenting properly when he wants to, which is my guess. If that is the case, that will cause severe issues when anyone else tries to read it! Debug code without indents also sounds like a bad idea to me. And even if you aren't a fan of Python's whitespace, I find that there are other features, such as using words instead of symbols (and, or, not instead of &&, ||, !) that definitely make Python one of the most readable languages out there.

4. Includes: I'm mixed on this one. On the one hand, I don't understand the first half of what he is saying, I have to go track down includes in any language. In Python at least I only have to deal with one include, whereas in C and C++ I have to go track down two, the header include and the actual library. This mostly seems to be complaining for the sake of complaining.

The last bit I personally agree with though. I once worked on a project that would analyze other people's Python code. At first Python seemed to do this extremely well as it can take any Python code and change it into its abstract syntax tree for further analysis. However, I soon found that in order to do this, it would have to execute any global code while it was reading it! I'm definitely not a fan of how Python technically runs anything it imports.

5. Nomenclature: Definitely unfair criticisms here. First, Python's lists aren't arrays but are lists! Arrays are blocks of unchanging memory, whereas lists are a structure that under the hood points to an array, but that array can be deleted and reallocated to resize it. I admit, I've never liked Python's word for dictionaries, but I don't like hash either, I think map is the better term, but it's still just a single name of a concept, not a huge deal. His arguments about the names of libraries are stupid, they are third party libraries that Python doesn't even control! And as someone who is very picky about function and variable names, a library name hardly ever matters, especially as Python allows you to rename imported modules.

6. Quirks: I don't even understand what his complaint is here. Does needing to triple quote multi-line strings really bother him that much? The binary and raw syntax might be a bit confusing, but I'll take that any day over C++'s L"" for wide strings and _T() for strings that may be wide or not and are determined at compile time. The string vs unicode is a bit confusing, I'll give him that, but I think the entire concept is confusing in any language.

7. Pass by object reference: I actually completely agree with him here, though I don't know how Python would fix this. I think I can explain it better than he does though. The issue is that if you create a list "list1" and then set "list2 = list1", and then append the element "3" to list2, list 1 changes as well even though list1 was never directly changed. This was one of the biggest things I struggled with in Python until I learned C++ better which taught me how Python was working under the hood. Python makes you think that it doesn't have pointers, but the truth is that everything in Python is a pointer, which I found confusing relative to how everything else in Python was beginner friendly.

8. Local names: I don't really understand his complaint here, don't shadow names.

Re: Reasons Python Sucks

#330
A great example of how Trump has been elected. He lied a lot, (or said stupid things because he was ignorant in a topic) but it doesn't matter, because rebuttal takes a bit more effort than saying stupid things so what he said stuck with a lot of people. Sorry, but this article is just ignorant in almost every point.
Post reply on HN