Live data from Hacker News

Reasons Python Sucks

hackerfactor.com

101–110 of 554 posts

Re: Reasons Python Sucks

#101

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…

> And I pity anyone who miscounts spaces and accidentally puts in three spaces instead of four somewhere -- this can take hours to debug and track down.

this is so hilariously wrong that it is clear that the author has never actually tried any of the things he complains about.

  Python 3.7.1 (default, Oct 22 2018, 10:41:28)
  [GCC 8.2.1 20180831] on linux
  Type "help", "copyright", "credits" or "license" for more information.
  >>> if True:
  ...     if True:
  ...         pass
  ...    pass
    File "", line 4
      pass
         ^
  IndentationError: unindent does not match any outer indentation level
same error in Python 2.7.15. the caret is at the wrong place, but the error message is perfectly fine on its own.

edit: I checked the CPython source, and this message actually dates back to 2000. so unless the author was using python 1.x back in the 90s, or is dumb enough to use single spaces for indentation, the story is a complete fabrication.

Re: Reasons Python Sucks

#102

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…

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, stupid examples. PyPy and PyPi (actually PyPI, with the uppercase) are not pronounced the same, its "pie-pie" and pie-P-I.

Second, on the package names, they're third-party. They could be named pretty much anything. Why does their naming matter in any way? I haven't seen much consistency in any language I've encountered anyway. I'd even say most of the examples he gave are at least pretty self-descriptive, compared to a lot of libs in multiple languages...

Re: Reasons Python Sucks

#103
post #93

Earlier quoted context omitted.

Most languages that use braces also encourage you to indent the things enclosed by the braces to make it easier to read. However, people sometimes make mistakes. For instance I've seen this quite a number of times if (a) somestatement; someotherstatement; athirdstatement; Which is of course horribly misleading unless you're careful because the second statement isn't actually conditional on a. Python forces the indent…

Does no one have auto indentation in their editors? Every so often I just select the block of code I'm editing and auto indent it, which matches indentation with semantics without me having to think about it. Annoyingly impossible to do this with python since indentation is semantics. It also results in copy pasting of code being 100 times harder in python than other languages.

That doesn't help with the problem you're replying to – in fact it would contribute to it.

More generally, yes, many people use auto-indenting and it works in Python in most editors. It's possible that you're using one where it doesn't work correctly but that doesn't mean that's true for everyone else.

Re: Reasons Python Sucks

#104

> My code for Python 3.5 won't work with the Python 3.7 installation unless I intentionally port it to 3.7. This statement is plain wrong at best and intentionally misleading at worst. 99.99% of Python 3.5 code runs unmodified on 3.7. > At the official Python web site, their documentation is actively maintained and available for Python 2.7, 3.5, 3.6, and 3.7 -- because they can't decide to give up on the old code. No…

afaik the only thing on python 3.7 that is backwards incompatible to 3.5 is:

> async and await are now reserved keywords.

so unless the author is using async/await as variable names (and i wonder why they would), 3.5 code is going to run as expected.

Re: Reasons Python Sucks

#106
post #23

Reason 2 is getting out of hand for Python, Ruby, JavaScript, Haskell and OCaml. These so called package manager can't manage packages at all. I'd like to call it package downloader. They just download everything from language interpreter to library to a single directory and call it job done. No easy way to remove the package. The interpreter and library's version is forever fixed. Theoretically, it can upgrade the v…

> They just download everything from language interpreter to library to a single directory and call it job done.

This is scoped to the project in npm. In Ruby, you can specify the path (common to "vendor" your gems). You can use version managers (like rvm or nvm) to scope your libs to versions or even named projects (thinking of rvm's "gemsets")

> The interpreter and library's version is forever fixed. Theoretically, it can upgrade the version but the user mostly don't.

I can't speak for all ecosystems, but on Ruby projects I've been a part of, keeping gems updated is pretty common. Github even includes monitoring for vulnerabilities to encourage this.

Having been part of ecosystems that don't have package management (for example, ColdFusion) even the worst package managers are a major improvement. (Though I do think the isolation of python's virtualenvs is a better approach than most systems)

Re: Reasons Python Sucks

#107
post #91

Earlier quoted context omitted.

Yes, but for a reference types that value IS a reference, so if you change a complex type, that change will persist after return to the calling code.

But it’s still pass by value. Passing by ref allows swapping out the entire object, which is not possible in a language such as JavaScript.

Right, but this is the same way Python works. Jumping back to the original argument in the post, the author claimed that Python was "going out of it's way to be different" by passing objects by reference value. C# provides a counterxample to that claim.

Re: Reasons Python Sucks

#108
I'm taking this article as a lesson in humility. It's really easy to concoct specious reasons for hating something, reasons you believe you've backed up with sound technical and philosophical arguments, but which are really just rationalizations for your failure to understand it.

Re: Reasons Python Sucks

#109
>> 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 everything is an object in python the passed _scalar_ values are references (addresses), the objects the references refer to are on the heap. I sometimes think literally everyone should have to use C for six months, most of this stuff would stop being debated endlessly.

Re: Reasons Python Sucks

#110
Actually, PyPI and PyPy are pronounced differently. The former is pronounced Pie-Pea-Eye, whereas the latter Pie-Pie.

"PyPI (Python Packaging Index): said aloud by using its full name, or by spelling out the last two letters, as in "Py-P-I". Alternatives are to abbreviate as the "Packaging Index", or to use the colloquial nickname "the Cheese Shop" (which refers to the name of a Monty Python's Flying Circus sketch). Referring to the packaging index aloud as "Py-Py" is strongly discouraged, as "PyPy" is the name of a popular alternative Python interpreter."

See, for example, https://github.com/pypa/python-packaging-user-guide/issues/8...

Post reply on HN