Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Reasons Python Sucks

hackerfactor.com

Post reply on HN
Print view View original

471–480 of 554 posts

Re: Reasons Python Sucks

#471

Post by gnulinux »

jMyles wrote: post #146

I saw "Reasons Python Sucks" on HN and I thought I was going to finally see an updated list of well-informed and articulated concerns about Python. Instead, this list is bizarre, misinformed, and largely incorrect. Other commenters have already pointed out several specifics. Two things I haven't seen yet that I'll add: > And I pity anyone who miscounts spaces and accidentally puts in three spaces instead of four some…

I 100% agree with you, but as a minor counterpoint, let me present you where an indentation might be a problem. I teach python (to my friends lol, not professionally) and a new learner apparently debugged this "for hours" (probably just 20 minutes).

   class A:
       def some_method(self):
            return # something

   def some_func(foo, bar):
       return # something
   
       def some_other_method(self):
           return # something
They intended to make `some_other_method` a method of class `A` instead they ended up writing `some_func` the wrong place and python parser was happy. For everyone except extreme python beginners debugging this will take 10 seconds. But just a datapoint.

Re: Reasons Python Sucks

#472

Post by qquark »

bakery2k wrote: post #307
earenndil wrote: post #275

Earlier quoted context omitted.

Type annotations don't seem to actually have any effect, though? Consider: >>> def add(a: int, b: int): ... return a+b ... >>> add("a", "b") 'ab' This should be an error, even if it's a runtime error.

There doesn't seem to be any interest in checking type annotations at run-time. Unfortunately, without doing so, type annotations look authoritative but are essentially just comments. I believe Julia is an example of a dynamically-typed language which does perform such checks at run-time - including as part of its support for multiple dispatch.

I've been using enforce for this purpose (https://github.com/RussBaz/enforce). It provides decorators that enable type checking where wanted. This gives the advantage of migrating existing code to type checking at your own pace at least.

On a general note I've come across a few cases, when pushing python's type annotations to their limits, that force you to put the type names in string quotes, and that makes the whole thing feel like a hack. It's better than nothing for my use cases, but if I remember correctly both mypy and enforce have problems in common that are probably coming from the way python itself is built, such as self reference in a class definition.

Re: Reasons Python Sucks

#473

Post by cutety »

laughingbovine wrote: post #361
cutety wrote: post #348

Earlier quoted context omitted.

Python was my first programming language, and though I don’t personally reach for it anymore (at least very rarely), it’s package management is the one large reason I don’t want to use it. All the other complaints I see about the language I don’t give much merit to, people like to complain, every language has it’s quirks and some people just can’t look past them. But, while not a solved problem, there are tons of gre…

Maybe you haven't used it in a while but requirements.txt lets you specify packages and lock (or unlock) the version.

Yeah, I’m aware you can pin versions in a requirements.txt, but does that also pin those packages dependencies? For example, if I had two pinned packages (A, B) and they both depend on package C, what happens if A updates to depend on a higher version of C that contains changes that break package B? Can you pessimistically (Gemfile ~>, or NPM ^) pin versions, or are you only limited to just equals X and the greater/less than operators?

Now that I’ve wrote that out, I’m wondering if packages can even pin their deps required versions. I’ve only published one python package years ago, and I can’t remember if that’s possible. Which I shouldn’t have to even worry about in a modern package management system.

I know the above example wouldn’t be possible in any of the systems I mentioned above, because the aside from installing packages, they ensure that the versions of every package are compatible. That’s why lockfiles are so important, assuming you’re downloading decent packages, the package manager can assure you that they’re all going to work together, also allowing you to update without having to worry about some random deeply nested dep isn’t going to break some other package when it gets updated, making updating (usually) a breeze.

In pips current state, it seems more or less like a slightly more strict NPM before yarn made them get their shit together (still vastly prefer yarn). The only difference is your packages are wherever Venv puts them instead in a “pip_modules” folder in the project, which is at least better than a global free-for-all. Though, that also might be less of a headache than dealing with Venv, I hope it’s gotten better since I’ve used it, because that was always such an annoyance.

Re: Reasons Python Sucks

#474

Post by dontreact »

saagarjha wrote: post #455
Zopieux wrote: post #416

Earlier quoted context omitted.

Though it doesn't take that much of an effort to just name your callback function and pass it as an argument. Python functions are first-class "objects" that can be passed around, use them! I've always found Python lambdas to be uncanny, weird and error prone. It's kinda syntactic sugar for expression-only defs with counterintuitive scope rules. I would recommend just not using them and fall back to named functions.…

This is extremely heavyweight syntax for something I like to use as a lightweight construct. If I wanted a function, I would make something a function.

x = lambda y:

def x(y):

What's so heavyweight? A new line and a tab?

Re: Reasons Python Sucks

#475

Post by joshuamorton »

trashcan wrote: post #441
toyg wrote: post #427

Earlier quoted context omitted.

> and that's it, you're done You are seriously comparing Maven, a huge and over-complicated xml-based system that is not even installed by default and that people hate so much that there are umpteen alternatives (gradle etc), with `pip install -r requirements.txt` that works out of the box? I just can't even... > Python still doesn't have anything [like Maven] And I thank the Gods for that.

> with `pip install -r requirements.txt` that works out of the box? Works out of the box until you're missing a distro package that is required to build a dependency that needs to be compiled from source. I've never used maven so I don't know if it is better or worse, but I am not a fan of languages having their own package management system that has not integration with the distro one (which probably also offers som…

At least with most packages this can't happen anymore.

If a package owner distributes a wheel, you're good. Most packages do now.

Re: Reasons Python Sucks

#476

Post by jMyles »

gnulinux wrote: post #471
jMyles wrote: post #146

I saw "Reasons Python Sucks" on HN and I thought I was going to finally see an updated list of well-informed and articulated concerns about Python. Instead, this list is bizarre, misinformed, and largely incorrect. Other commenters have already pointed out several specifics. Two things I haven't seen yet that I'll add: > And I pity anyone who miscounts spaces and accidentally puts in three spaces instead of four some…

I 100% agree with you, but as a minor counterpoint, let me present you where an indentation might be a problem. I teach python (to my friends lol, not professionally) and a new learner apparently debugged this "for hours" (probably just 20 minutes). class A: def some_method(self): return # something def some_func(foo, bar): return # something def some_other_method(self): return # something They intended to make `some…

Yes, now that's a legitimate demonstration of a possible weak point of syntactic indentation.

But it's easily fixed with code collapsing tools or a structure viewer (both of which are provided in all of the major python IDEs).

Re: Reasons Python Sucks

#477

Post by joshuamorton »

cutety wrote: post #348
blattimwind wrote: post #222

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.

Python was my first programming language, and though I don’t personally reach for it anymore (at least very rarely), it’s package management is the one large reason I don’t want to use it. All the other complaints I see about the language I don’t give much merit to, people like to complain, every language has it’s quirks and some people just can’t look past them. But, while not a solved problem, there are tons of gre…

Pipenv and poetry both provide lock files. Both handle virtualenvs and version resolution.

Re: Reasons Python Sucks

#478

Post by joshuamorton »

earenndil wrote: post #275
closed wrote: post #116

Earlier quoted context omitted.

> I regularly wish python required some sort type indication for function parameters You can use type annotations, either via the builtin lib or 3rd party libs! https://docs.python.org/3/library/typing.html > do_x() if a.y() I feel this. You can use `a.y() and do_x()`, but I'm not sure how people would react :o

Type annotations don't seem to actually have any effect, though? Consider: >>> def add(a: int, b: int): ... return a+b ... >>> add("a", "b") 'ab' This should be an error, even if it's a runtime error.

Type annotations have no effect by default. You're free to use a tool to do compile or runtime checking though.

Re: Reasons Python Sucks

#479

Post by juststeve »

bscphil wrote: post #325
toyg wrote: post #183

Earlier quoted context omitted.

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.

Rust has a REPL under development on github: https://github.com/murarth/rusti

Seems to be active up until around July-August

Re: Reasons Python Sucks

#480

Post by joshuamorton »

unethical_ban wrote: post #448
riskable wrote: post #210

Earlier quoted context omitted.

I asked a "C all the things!" developer a while back why he hated Python's enforced indentation and in a whole lot of words he basically said that it makes it difficult to visually track scope when you have long chains of conditionals. The standard Python developer response to that is, "Aha! You like braces because they enable your bad programming practices !" However, I found the best way to illustrate that point is…

Literally anything other than spaces that allowed easier linting, less "wait am I doing it right" regarding multi-line statements, etc. If that is a keyword, or brackets, or whatever, I would prefer that. You can't minify or easily lint python. And you can't easily tell if there are mixed indent methods (tabs/spaces) and IDEs struggle with it vs. a simple bracket structure. (This is a rare repost within a thread. I'm…

What linting is difficult in Python?

I find that the linting available in Python is better than that in c++, though c++ has better auto complete.

Minification of most of Python is possible, although shouldn't be considered of any value since it's not passed over the wire to a user.

Post reply on HN