Live data from Hacker News

Reasons Python Sucks

hackerfactor.com

181–190 of 554 posts

Re: Reasons Python Sucks

#181
post #64

Earlier quoted context omitted.

> Take lists: some operations are methods, some are functions, some mutate the list, some make a copy, some are global, some are in a module. Let's take the list type, the public methods are: 'clear', 'copy', 'count', 'extend', 'index', 'insert', 'pop', 'remove', 'reverse', 'sort' Obviously as the names imply `copy` returns a new list, and `count` returns an integer. Neither mutate the list. For the rest of it: metho…

OK, fair point. I misremembered the list interface. `set` is a better example: `set.union`, for example, returns a new set, while `set.add` updates in place. (To be fair, this is with Python 2.7, maybe Python 3+ is more uniform?)

What would you expect it to do differently in those cases? That seems like the API is following how most people would think about those operations as you'd expect in a language which isn't trying to be immutable.

Re: Reasons Python Sucks

#182
One of my biggest gripe is how python have a hidden non-declared agenda to have syntax as far from C as possible.

its really not giving language any usage benefits when you cannot use ternary expressions, ! as not, !=, increment operators.

Also, PEP8 is very very presriptive, you are disallowed to do violate any rule, even when if you need to to make the code better. (I feel shunned by the community for not liking 80 chars line hard breaks)

Python3 migration was not planned well - the lack of back and forward compatibility gave users a legit reason to stay with python 2 forever. I've seen some conference talks where end users/projects being shamed for not jumping on python3.

GIL in python is something that was talked about 5 years ago and will still be talked in 5 years. It limits the ability of python to reap the benefits of better hardware.

This may be minor, but I really missing ruby rich set of collection methods: take_while, group_by, sample. Yet I can see a point in extracting that to a external library.

Of course, all this does not mean python is not good. Builtin pip/venv, adrequate unicode in python3, some of fantastic libraries(numpy/scipy, bokeh) making it indispensable.

Re: Reasons Python Sucks

#183
post #119

Most of the points in this article fall on a continuum between irrelevant to dead wrong. 1 (versions) and 2 (installation) have to do with the ecosystem, not the language. Unsigned packages are a real problem, but hating on community-maintained software is just weird. Most software in your local Linux distro's repository is maintained by a "community" that might just be one person working in their spare time. 3 (synt…

> 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 box. How many languages pack an editor ready to go? Or a way to install modules with a single command? Not even Java, with all its commercial might, ever achieved that - it barely got a REPL last year, which Python has had for what, 20 years now?

What people decry about “the Python ecosystem” is simply a function of its success as a generalist computing language over 25 years. Nobody uses Typescript to build Linux distributions; nobody uses Go to build lib-gluing GUI apps; nobody uses Rust to write spreadsheet formulas. Python does all that (and more), and this of course resulted in a sprawling community, with tools pulled every other way. If any of your new shiny languages will ever achieve a similar level of popularity, you can bet their ecosystem will also become a complete mess.

Re: Reasons Python Sucks

#184
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…

Your comment is a great argument for languages that make compromises to be good at some domains and not others. I’ve hated every general-purpose language I’ve ever used, and the ecosystem mess is probably why.

Re: Reasons Python Sucks

#185

Earlier quoted context omitted.

The article read more like a rant of "I PERSONALLY HATE THIS" than a well-reasoned argument of why the language might actually suck. Here's an example : > PyPy, PyPi, NumPy, SciPy, SymPy, PyGtk, Pyglet, PyGame... (Yes, those first two are pronounced the same way, but they do very different things.) I understand that the 'py' is for Python. But couldn't they be consistent about whether it comes first or second? First,…

> The article read more like a rant of "I PERSONALLY HATE THIS" Given the entire premise of the post is that he's written a list of things he hates about Python as an answer to his friend's question as to why he hates Python, I'm not sure why you think there's some ambiguity here.

Which makes it perplexing that it's on the HN front page. A list of very personal and petty gripes aren't all that informative. Especially when half of them seem to show a profound lack of familiarity with Python.

Re: Reasons Python Sucks

#186

>> Most programming languages pass function parameters by value. If the function alters the value, the results are not passed back to the calling code. But as I've already explained, Python goes out of its way to be different. Python defaults to doing functions with pass-by-object-reference parameters. Python passes method arguments by value, pushing them on the stack like every other language I've used. Because ever…

Everything in Python may be an object in some technical sense. Semantically, everything isn't. The utility of "everything is an object" is as a promise that lets programmers write: 3.fizzbuzz # returns "fizz" 5.fizzbuzz # returns "buzz" 7.fizzbuzz # returns 7 15.fizzbuzz # returns "fizzbuzz" as is the case with Ruby or Smalltalk. I think that the author's complaints center around Python behaving like C sometimes and…

You can't add methods to integers in Python, but they're still objects in the sense that you can call methods on them:

>>> i = 123

>>> i.bit_length()

7

Re: Reasons Python Sucks

#187

Most of the points in this article fall on a continuum between irrelevant to dead wrong. 1 (versions) and 2 (installation) have to do with the ecosystem, not the language. Unsigned packages are a real problem, but hating on community-maintained software is just weird. Most software in your local Linux distro's repository is maintained by a "community" that might just be one person working in their spare time. 3 (synt…

> 7 (pass by reference) is another totally-wrong one.

Yes, specially cos it is not "pass by reference", but "call by sharing"

http://www.effbot.org/zone/call-by-object.htm

https://en.wikipedia.org/wiki/Evaluation_strategy#Call_by_sh...

Re: Reasons Python Sucks

#188

>> Most programming languages pass function parameters by value. If the function alters the value, the results are not passed back to the calling code. But as I've already explained, Python goes out of its way to be different. Python defaults to doing functions with pass-by-object-reference parameters. Python passes method arguments by value, pushing them on the stack like every other language I've used. Because ever…

Everything in Python may be an object in some technical sense. Semantically, everything isn't. The utility of "everything is an object" is as a promise that lets programmers write: 3.fizzbuzz # returns "fizz" 5.fizzbuzz # returns "buzz" 7.fizzbuzz # returns 7 15.fizzbuzz # returns "fizzbuzz" as is the case with Ruby or Smalltalk. I think that the author's complaints center around Python behaving like C sometimes and…

Are you after monkey patching, where you can add new methods outside of the class definition? That's not really a standard feature of all object orient languages - Java doesn't do that, for instance.

Python integers are definitely objects:

    (3).real # returns 3
    (3).imag # returns 0
Python's lexer/parser made different choices than Ruby's, so the parens are needed here.

Re: Reasons Python Sucks

#189

Most of the points in this article fall on a continuum between irrelevant to dead wrong. 1 (versions) and 2 (installation) have to do with the ecosystem, not the language. Unsigned packages are a real problem, but hating on community-maintained software is just weird. Most software in your local Linux distro's repository is maintained by a "community" that might just be one person working in their spare time. 3 (synt…

> 1 (versions) and 2 (installation) have to do with the ecosystem, not the language.

How exactly do I use Python while entirely avoiding the Python ecosystem?

I get what you're saying but you're also massively nitpicking. His point is correct.

Re: Reasons Python Sucks

#190
post #117

Earlier quoted context omitted.

Python (and Java) do not pass anything by reference. They pass by pointer-value. (If they passed by reference, you could change to which value a caller's variable was bound, like you can in C++).

> They pass by pointer-value. No, Python doesn't even do that, because Python variables aren't names for storage locations to begin with. They're namespace bindings. Passing a variable to a Python function means transferring a namespace binding from the caller's namespace to the function's local namespace.

What is a namespace binding? Can you explain at a low level what that means?
Post reply on HN