7 ms·

Reasons Python Sucks (2018)

23 points by warent 4y ago

biggerChris 4y ago
[dead]
29athrowaway 4y ago
Reason 0: eggs and wheels
wendyshu 4y ago
There are legitimate criticisms to be made of Python but this is a pretty poor list.
mmcnl 4y ago
Overopinionated engineers are annoying. Python doesn't suck, everyone knows that. Every language has its strengths and weaknesses. Clickbaity.
- CryptoChronicon 4y ago
  Clickbaity maybe, because it’s a controversial topic. What is the line between opinionated and over-opinionated?
  - tooltower 4y ago
    The tone, which often shows an unwillingness to learn. The lack of humility. Confidently stating or broadcasting facts without acknowledging why others might disagree.
  - jim_and_derrick 4y ago
    [dead]
- mixmastamyk 4y ago
  Amateur night at the HN corral. Open mic until close. (Slashdot wants their post back, haha.)
- Aeolun 4y ago
  > 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.
  - acdha 4y ago
    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 embedded systems a lot of people will likely agree that Python isn’t a great fit but also that experience is only partially relevant to someone who builds web apps or works in data science.
    - Aeolun 4y ago
      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.
      - asplake 4y ago
        By comparison, in context. Context really is everything here
- layer8 4y ago
  It would be an okay provocative title if the criticism was well-founded (which can certainly be done for Python), but most of the article is rather poor.
bsder 4y ago
Ayup. If you have these same points of view that the author does: please don't use Python. There is no shortage of languages out there that would be a better match for you--please use one of those. However, the packaging and installation thing is very valid--Python really sucks at that and needs to fix it.
aeturnum 4y ago
Many of these things are annoying, but I wanna check something.... Lists in python are called lists because they're linked lists right? They are not called arrays because they are a different data structure. Edit: Well TIL! Thanks everyone.
- raymondh 4y ago
  Nope.
- lights0123 4y ago
  No, lists are implemented in CPython as an regular, contiguous array of PyObject. There is an array library (https://docs.python.org/3/library/array.html https://docs.python.org/3/library/array.html) for more efficient storage, comparable to JS's Uint8Array and friends.
- LightHugger 4y ago
  lists are arrays with different data types allowed per index
- pdonis 4y ago
  > Lists in python are called lists because they're linked lists right? No. At the C level in the interpreter they are arrays of object pointers. > They are not called arrays because they are a different data structure. No. They're not called arrays because Python uses the name "array" for something else: https://docs.python.org/3/library/array.html https://docs.python.org/3/library/array.html
  - hiq 4y ago
    How widely are Python arrays used in practice?
    - pdonis 4y ago
      I haven't had much occasion to use them. I suspect that most use cases nowadays where the speed advantage is needed involve numerical computing where the user is probably using a library like numpy or scipy and will use their array implementation, not the built-in Python one. However, arrays have been around in Python since very early on, when those other numerical libraries didn't exist, so the array built-in might have gotten more use then.
lights0123 4y ago
"Reason 7: Pass By Object Reference": isn't this the case of almost every GC'd language? Java, JS, PHP, Swift, and C# all do so, although C# doesn't if your type is a "struct" not a class. Go is the only popular exception I can think of.
- deleted 4y ago
  [deleted]
- Barrin92 4y ago
  any language with immutability by default, say Clojure.
  - ErikCorry 4y ago
    If the object is immutable you can't really tell if it was passed by value or by reference. It becomes an implementation detail.
    - eyelidlessness 4y ago
      Yep, one of the theoretical promises of FP that’s totally vindicated (unless there’s a language bug, but they usually get this much right). And because you can’t tell, you don’t need to care. For folks working in imperative languages, you can achieve this same bliss by either not modifying your function parameters in the first place (hopefully this is obvious if you care about the distinction and find the language behavior ambiguous)… or by just doing whatever copy/clone/value transfer would be appropriate as a first step if you have good reason to modify the value of a parameter to your otherwise pure function.
- pdonis 4y ago
  Python is actually different in that the whole "pass by value" vs. "pass by reference" distinction doesn't really apply. At the C level, yes, every Python object is "passed by reference" in the sense that pointers to its C structure are what get passed around. But at the Python level, Python "variables" aren't labels for memory locations, as they are in other languages; they're namespace bindings. And a function can't access the caller's namespace at all unless the global or nonlocal keywords are explicitly used. So in many ways Python's function call semantics are more like "pass by value" than "pass by reference"; but they're really not quite the same as either one.
vhguru 4y ago
Reason 2 seems to indicate that the author doesn’t understand how Linux distributions work either, in addition to Python.
pdonis 4y ago
Tl/dr: Author is under the misapprehension that "I hate Python" and "Python sucks" are the same thing.
VincentEvans 4y ago
Some of his complaints are best addressed by using an IDE. I use Pycharm.
fzliu 4y ago
This feels like it was written by someone who has been writing C code their entire life.
kbenson 4y ago
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't want to switch. That's not to defend Python versioning though, which as a sysadmin supporting devs is always a pain point.
throway3223422 4y ago
Those aren't reasons why python sucks, but these are. * The standard library still sucks * The documentation still sucks * Dependency management still sucks (unless you cope with poetry). * it doesn't have CPAN * It's not a lisp
pdonis 4y ago
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 "by reference". It passes object pointers, but you can't "mutate" an object pointer; it will always point to the same object forever. What this author doesn't seem to get is that in Python, "variables" aren't labels for memory locations; they'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's namespace. Which means that, in effect, Python variables are passed "by value" to functions--the function can only work with the object it was passed, it can't mess with the namespace it was passed from. What does often trip up new Python programmers is that if you pass a mutable object, like a list or a dict, to a function, the function can 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. "Calling the same object by different names doesn't change the object, so it is effectively global." I think this person simply doesn't understand how Python works.
- Aeolun 4y ago
  > I think this person simply doesn't understand how Python works. To be fair, if Python does something that is so different from all other languages maybe that’s a complaint in itself, even if the original complaint is invalid.
  - Redoubts 4y ago
    Do you think it does? CS is a field with many wild ideas and I don’t think python is that far into the weeds. Definitely not around 2018 when this was written. A lot of it’s big problems are 90s-scripting-language problems.
  - deleted 4y ago
    [deleted]
  - 4y ago
microtherion 4y ago
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). 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.
- Aeolun 4y ago
  Ah yes, miniconda. Clearly that’s about managing Python versions (and dependencies)? Why can’t we just call it python-version-manager? But then what would we call the other 15 methods of managing python dependencies/versions?
ErikCorry 4y ago
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.
- 323 4y ago
  > Misspelling a variable creates a new one. IDEs/linters help with this one. > Type annotations are ignored, so nobody bothers If one really cares you can use MyPy to force errors on bad types. Type annotations are very useful for IDEs, which is why they are spreading fast in the ecosystem.
- mjr00 4y ago
  > * Type annotations are ignored, so nobody bothers. For any serious Python app worked on by multiple people, you need a CI pipeline that runs type checking. (And while you're there, run a format checker like black, too -- solves the tabs vs spaces "debate" the author complains about as well) Certainly still a language flaw that it's not inherently enforced, though; unfortunately it just took the Python community way too long to realize how important strong typing is at scale.
- raymondh 4y ago
  Indeed, this list is better.
- aYsY4dDQ2NrcNzA 4y ago
  You probably already know that __init__() isn’t a constructor, technically; it’s an initializer.
sli 4y ago
I was actually interested to read a list of quirks, especially since I haven't used Python in quite a while now and the author claims it has more quirks than any other language they've ever seen. And yet, the only example is the relatively easy to understand quoting. What is this article actually for?
Redoubts 4y ago
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.” Although if I made a list it probably wouldn'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'm surprised more languages don't make this very easy! Reason 3, I can't care about the whitespace debate anymore. But > Deep nesting is permitted, but lines can get so wide that they wrap lines in the text editor. ??? This article is 5 years old, and we have black now to solve this; but I'm pretty sure most production code bases have had hard line limits in the style guide. Reason 4, > Finding a list of what can be imported is non-intuitive. With C, you can just look in /usr/include/*.h. But with Python? It's best to use 'python -v' to list all of the places it looks, and then search every file in every directory and subdirectory from that list I don't think C/C++ is actually that much better at this? > In contrast, many Python modules include initialization functions that run during the import. They can but they commonly don't. A lot of python is about "we're all adults here", and that works surprisingly well. Reason 5 > In every other language, arrays are called 'arrays'. In Python, they are called 'lists'. I mean there's a good reason for that, and I don't think C++ would call that data structure an `array` either. > Python seems to go out of it's way to not use the common terms found Honestly CS loves to give +3 names to basic things all over, this isn't new to python. I don't think the author's chosen ones are correct. Reason 6, I think newer languages are doing similar things with strings that python did, so I'm gonna say the wider community things this was a decent thing to do. And I'm not sure triple quotes is as complicated as =/==/=== in JS. Reason 7, > This means that changing the source variable may end up changing the value. If you mutate an object I'm not surprised the change is propagated. But there are immutable values, notably strings, that will not work this way. I can't say this author shows much experience with any language in depth. Reason 8, I don't think I've ever heard of someone complain about namespacing like this, and then compliment C. These reasons all feel the like "it's not like the first language I used" rather than real issues. 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!
- 4y ago
dang 4y ago
Discussed at the time: Reasons Python Sucks - https://news.ycombinator.com/item?id=18706174 https://news.ycombinator.com/item?id=18706174 - Dec 2018 (535 comments)
jszymborski 4y ago
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? Sure. But I personally feel worse about python the more complex a library I'm writing gets.
- nicbou 4y ago
  This is a flaw with many other languages. Static types save you a lot of headaches past a certain size.
deleted 4y ago
[deleted]
lyjackal 4y ago
I agree with the sentiment that these reasons are terrible. My main gripes: - the half hearted take on static types - excessive use of mutability and imperative programming - dependency, version management and compatibility. 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/miniconda).
xyst 4y ago
I just want to say, working with python in an air gapped environment is fucking painful too. I am not working with it directly but indirectly with ansible, and one of the playbooks (or "collections" 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'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't find anything. On the other hand, I do appreciate python's concise syntax and makes it easy to write a few powerful one liners.
layer8 4y ago
> an associative array is sometimes called a 'hash' (Perl), but Python calls it a 'dictionary'. Python seems to go out of it's way to not use the common terms found throughout the computer and information science field. 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: https://www.nist.gov/dads/HTML/dictionary.html https://www.nist.gov/dads/HTML/dictionary.html
eyelidlessness 4y ago
I haven’t had skin in the game for years, so my opinion isn’t super valuable here. Anyway, some of this is valid, albeit a lot of that is either well trodden (eg py3 gripes, pros/cons of significant whitespace) or host environment/tooling specific (eg where a thing installs `python` and which version without additional qualification and whether that’s stable). But some of this is surprisingly mind boggling! I interrupted my reading of it somewhere in the beginning of > Reason 7: Pass By Object Reference The author spends quite a lot of time expressing familiarity with not just their preferred language C but demonstrating fairly intimate familiarity with several 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. Huh? 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!) 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.
blacklight 4y ago
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.
blacklight 4y ago
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.
revskill 4y ago
Python is selfish ;)

23 points by warent 4y ago

biggerChris 4y ago

[dead]

29athrowaway 4y ago

Reason 0: eggs and wheels

wendyshu 4y ago

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

mmcnl 4y ago

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

CryptoChronicon 4y ago
Clickbaity maybe, because it’s a controversial topic. What is the line between opinionated and over-opinionated?
- tooltower 4y ago
  The tone, which often shows an unwillingness to learn. The lack of humility. Confidently stating or broadcasting facts without acknowledging why others might disagree.
- jim_and_derrick 4y ago
  [dead]
mixmastamyk 4y ago
Amateur night at the HN corral. Open mic until close. (Slashdot wants their post back, haha.)
Aeolun 4y ago
> 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.
- acdha 4y ago
  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 embedded systems a lot of people will likely agree that Python isn’t a great fit but also that experience is only partially relevant to someone who builds web apps or works in data science.
  - Aeolun 4y ago
    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.
    - asplake 4y ago
      By comparison, in context. Context really is everything here
layer8 4y ago
It would be an okay provocative title if the criticism was well-founded (which can certainly be done for Python), but most of the article is rather poor.

bsder 4y ago

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

aeturnum 4y ago

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

raymondh 4y ago
Nope.
lights0123 4y ago
No, lists are implemented in CPython as an regular, contiguous array of PyObject. There is an array library (https://docs.python.org/3/library/array.html https://docs.python.org/3/library/array.html) for more efficient storage, comparable to JS's Uint8Array and friends.
LightHugger 4y ago
lists are arrays with different data types allowed per index
pdonis 4y ago
> Lists in python are called lists because they're linked lists right? No. At the C level in the interpreter they are arrays of object pointers. > They are not called arrays because they are a different data structure. No. They're not called arrays because Python uses the name "array" for something else: https://docs.python.org/3/library/array.html https://docs.python.org/3/library/array.html
- hiq 4y ago
  How widely are Python arrays used in practice?
  - pdonis 4y ago
    I haven't had much occasion to use them. I suspect that most use cases nowadays where the speed advantage is needed involve numerical computing where the user is probably using a library like numpy or scipy and will use their array implementation, not the built-in Python one. However, arrays have been around in Python since very early on, when those other numerical libraries didn't exist, so the array built-in might have gotten more use then.

lights0123 4y ago

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

deleted 4y ago
[deleted]
Barrin92 4y ago
any language with immutability by default, say Clojure.
- ErikCorry 4y ago
  If the object is immutable you can't really tell if it was passed by value or by reference. It becomes an implementation detail.
  - eyelidlessness 4y ago
    Yep, one of the theoretical promises of FP that’s totally vindicated (unless there’s a language bug, but they usually get this much right). And because you can’t tell, you don’t need to care. For folks working in imperative languages, you can achieve this same bliss by either not modifying your function parameters in the first place (hopefully this is obvious if you care about the distinction and find the language behavior ambiguous)… or by just doing whatever copy/clone/value transfer would be appropriate as a first step if you have good reason to modify the value of a parameter to your otherwise pure function.
pdonis 4y ago
Python is actually different in that the whole "pass by value" vs. "pass by reference" distinction doesn't really apply. At the C level, yes, every Python object is "passed by reference" in the sense that pointers to its C structure are what get passed around. But at the Python level, Python "variables" aren't labels for memory locations, as they are in other languages; they're namespace bindings. And a function can't access the caller's namespace at all unless the global or nonlocal keywords are explicitly used. So in many ways Python's function call semantics are more like "pass by value" than "pass by reference"; but they're really not quite the same as either one.

vhguru 4y ago

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

pdonis 4y ago

Tl/dr: Author is under the misapprehension that "I hate Python" and "Python sucks" are the same thing.

VincentEvans 4y ago

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

fzliu 4y ago

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

kbenson 4y ago

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't want to switch. That's not to defend Python versioning though, which as a sysadmin supporting devs is always a pain point.

throway3223422 4y ago

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

pdonis 4y ago

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 "by reference". It passes object pointers, but you can't "mutate" an object pointer; it will always point to the same object forever. What this author doesn't seem to get is that in Python, "variables" aren't labels for memory locations; they'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's namespace. Which means that, in effect, Python variables are passed "by value" to functions--the function can only work with the object it was passed, it can't mess with the namespace it was passed from. What does often trip up new Python programmers is that if you pass a mutable object, like a list or a dict, to a function, the function can 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. "Calling the same object by different names doesn't change the object, so it is effectively global." I think this person simply doesn't understand how Python works.

Aeolun 4y ago
> I think this person simply doesn't understand how Python works. To be fair, if Python does something that is so different from all other languages maybe that’s a complaint in itself, even if the original complaint is invalid.
- Redoubts 4y ago
  Do you think it does? CS is a field with many wild ideas and I don’t think python is that far into the weeds. Definitely not around 2018 when this was written. A lot of it’s big problems are 90s-scripting-language problems.
- deleted 4y ago
  [deleted]
- 4y ago

microtherion 4y ago

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). 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.

Aeolun 4y ago
Ah yes, miniconda. Clearly that’s about managing Python versions (and dependencies)? Why can’t we just call it python-version-manager? But then what would we call the other 15 methods of managing python dependencies/versions?

ErikCorry 4y ago

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.

323 4y ago
> Misspelling a variable creates a new one. IDEs/linters help with this one. > Type annotations are ignored, so nobody bothers If one really cares you can use MyPy to force errors on bad types. Type annotations are very useful for IDEs, which is why they are spreading fast in the ecosystem.
mjr00 4y ago
> * Type annotations are ignored, so nobody bothers. For any serious Python app worked on by multiple people, you need a CI pipeline that runs type checking. (And while you're there, run a format checker like black, too -- solves the tabs vs spaces "debate" the author complains about as well) Certainly still a language flaw that it's not inherently enforced, though; unfortunately it just took the Python community way too long to realize how important strong typing is at scale.
raymondh 4y ago
Indeed, this list is better.
aYsY4dDQ2NrcNzA 4y ago
You probably already know that __init__() isn’t a constructor, technically; it’s an initializer.

sli 4y ago

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

Redoubts 4y ago

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.” Although if I made a list it probably wouldn'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'm surprised more languages don't make this very easy! Reason 3, I can't care about the whitespace debate anymore. But > Deep nesting is permitted, but lines can get so wide that they wrap lines in the text editor. ??? This article is 5 years old, and we have black now to solve this; but I'm pretty sure most production code bases have had hard line limits in the style guide. Reason 4, > Finding a list of what can be imported is non-intuitive. With C, you can just look in /usr/include/*.h. But with Python? It's best to use 'python -v' to list all of the places it looks, and then search every file in every directory and subdirectory from that list I don't think C/C++ is actually that much better at this? > In contrast, many Python modules include initialization functions that run during the import. They can but they commonly don't. A lot of python is about "we're all adults here", and that works surprisingly well. Reason 5 > In every other language, arrays are called 'arrays'. In Python, they are called 'lists'. I mean there's a good reason for that, and I don't think C++ would call that data structure an `array` either. > Python seems to go out of it's way to not use the common terms found Honestly CS loves to give +3 names to basic things all over, this isn't new to python. I don't think the author's chosen ones are correct. Reason 6, I think newer languages are doing similar things with strings that python did, so I'm gonna say the wider community things this was a decent thing to do. And I'm not sure triple quotes is as complicated as =/==/=== in JS. Reason 7, > This means that changing the source variable may end up changing the value. If you mutate an object I'm not surprised the change is propagated. But there are immutable values, notably strings, that will not work this way. I can't say this author shows much experience with any language in depth. Reason 8, I don't think I've ever heard of someone complain about namespacing like this, and then compliment C. These reasons all feel the like "it's not like the first language I used" rather than real issues. 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!

4y ago

dang 4y ago

Discussed at the time: Reasons Python Sucks - https://news.ycombinator.com/item?id=18706174 https://news.ycombinator.com/item?id=18706174 - Dec 2018 (535 comments)

jszymborski 4y ago

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? Sure. But I personally feel worse about python the more complex a library I'm writing gets.

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

deleted 4y ago

[deleted]

lyjackal 4y ago

I agree with the sentiment that these reasons are terrible. My main gripes: - the half hearted take on static types - excessive use of mutability and imperative programming - dependency, version management and compatibility. 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/miniconda).

xyst 4y ago

I just want to say, working with python in an air gapped environment is fucking painful too. I am not working with it directly but indirectly with ansible, and one of the playbooks (or "collections" 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'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't find anything. On the other hand, I do appreciate python's concise syntax and makes it easy to write a few powerful one liners.

layer8 4y ago

> an associative array is sometimes called a 'hash' (Perl), but Python calls it a 'dictionary'. Python seems to go out of it's way to not use the common terms found throughout the computer and information science field. 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: https://www.nist.gov/dads/HTML/dictionary.html https://www.nist.gov/dads/HTML/dictionary.html

eyelidlessness 4y ago

I haven’t had skin in the game for years, so my opinion isn’t super valuable here. Anyway, some of this is valid, albeit a lot of that is either well trodden (eg py3 gripes, pros/cons of significant whitespace) or host environment/tooling specific (eg where a thing installs `python` and which version without additional qualification and whether that’s stable). But some of this is surprisingly mind boggling! I interrupted my reading of it somewhere in the beginning of > Reason 7: Pass By Object Reference The author spends quite a lot of time expressing familiarity with not just their preferred language C but demonstrating fairly intimate familiarity with several 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. Huh? 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!) 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.

blacklight 4y ago

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.

blacklight 4y ago

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.

revskill 4y ago

Python is selfish ;)