Live data from Hacker News

Reasons Python Sucks

hackerfactor.com

231–240 of 554 posts

Re: Reasons Python Sucks

#231
The random complaint about Perl version compatibility was particularly bizarre. There was really no incompatibility between Perl 3 and 4. Then I guess all those people got fed up and quit using Perl when they made the next version and it was left in, what? a 15 year glory period where several orders of magnitude more software was written with it?

Talking about how there's very little new software written in Perl now is definitely using post-hoc reasoning. There's probably a language named after a British comedy troupe that is somewhat responsible.

Re: Reasons Python Sucks

#232

Earlier quoted context omitted.

Indeed. My personal bugbear is lack of multiline lambdas. I use these all the freaking time in JS and it's infuriating that I can't in python. At the end of the day it's a minor complaint of course.

I think it makes more sense in a language where you have to write callbacks all the time. I consider it a feature in Python, because by using `def` you're forced to imbue the function with meaning by providing it a name. Otherwise, it's just reading through a potentially complicated function without any context of what it's supposed to be doing.

All languages, including python, where you do a lot of asynchronous io require callbacks all the time. It's only recently python got await-support to deal with this. Single line lambdas is a real PITA when your not using asyncio and python maintainers have said they don't plan to change it :(

Re: Reasons Python Sucks

#233
post #191

Earlier quoted context omitted.

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.

> and i wonder why they would It's easy, actually: import asyncio @asyncio.async # SyntaxError in 3.7 def my_coroutine(...): ... And since asyncio is one of the strongest reason to migrate to python 3.x, I bet far less than 99.99% of code written for 3.4/3.5 can be run on 3.7 with no changes. Luckly, 99% of changes were trivial. Other 1% is a nightmare.

Using async and await as non-keywords was deprecated since 3.5, while asyncio.async was deprecated since 3.4.

Re: Reasons Python Sucks

#234

Earlier quoted context omitted.

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

Some methods but not others. Specifically, I can call built-in methods, but not methods I define. For example:

  >>> def f(self):
  ...   return self
  ... 
  >>> (3).f
  Traceback (most recent call last):
    File "", line 1, in 
    AttributeError: 'int' object has no attribute 'f'

Re: Reasons Python Sucks

#235

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?

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

Re: Reasons Python Sucks

#237

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…

Every value in Python is a reference to an object. All function parameters are such values that are passed as they are. You get the same references to objects that the caller passed. We could call this "passing references to objects by value."

That's a long form of what I most often hear: "pass by value of reference"

But in any case, that's the point that made me go wtf while reading through as well. Whatever you want to call it, it's the same as what C (when not passing pointers), Java, PHP, Javascript, and many many other languages use.

Which is why it's so frustrating we don't have a good, easily-understood/well-known name for it.

Re: Reasons Python Sucks

#238
For me, the siren call of Python was the supposed "elegance" (executable pseudo code!). But then you have these horrible non-composing list comprehensions (compared to say Ruby where the chain just flows from left to right instead of getting more and more nested), and that god awful "self" and "__init__" cruft. It just seems like a poorly designed (and/or evolved?) language.

It'd be nice if something else would carry the torch for nice AI library wrapper language...that alone is the only thing that can tempt me touch it.

Re: Reasons Python Sucks

#239
post #227

Earlier quoted context omitted.

I think the problem he is describing--somewhat poorly--is when the "third space" just happens to match some other scope above, and therefore is syntactically valid, but not nested the way one initially thought. Those kinds of problems can be hard to track down.

These kind of problems can be solved or avoided altogether by a decent editor.

I don't see how. An editor can help you get indentations that are syntactically valid, but can't possibly know if the programmer intends the program below to print plain "foo" or both "foo" and "bar".

  print("foo")
  # x is false for the problem
  if x:
    do_something()

    print("bar")

And to the parent who has written a lot of code but never had this problem, well, some people do.

Re: Reasons Python Sucks

#240

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.

I think the issue is that the article is called "Reasons Python Sucks" rather than "Things I Hate About Python". It comes off as the author saying that these things are objectively bad about python even though many of them are clearly subjective.
Post reply on HN