Live data from Hacker News

Reasons Python Sucks

hackerfactor.com

341–350 of 554 posts

Re: Reasons Python Sucks

#341

Earlier quoted context omitted.

>3 (syntax) seems to be about not supporting the author's own highly idiosyncratic habits Yeah, I don't get the author at all. Using indentation is so, so, so, so, much cleaner and easier to understand, even with lots of nesting than trying to figure out if you closed all the stupid curly braces, curly braces be damned.

Yes, we indent code for readability sake. If you don't, that would be incompetent. Which makes the braces redundant at best, noise at worst. Their lack in Python bothered me too, one afternoon in the spring of 2001, then I moved on. When I hear someone complaining about it I immediately think, this person hasn't much experience with Python, or is one of those highly inflexible pedant types.

>Which makes the braces redundant at best, noise at worst.

YES!! Every time I try something other than Python that requires braces, I am like "WTF, why do I have to type this extra shit! Such an annoyance."

Re: Reasons Python Sucks

#342

Earlier quoted context omitted.

As a former certified Java programmer, moving to Python was a breath of fresh air. More concise syntax, no more braces all over the place, much less boilerplate (think getter, setter, public static void main(String[] args)) and not everything has to be an object. First-class functions, yay ! (I haven’t used Java seriously since 1.6 so I don’t know how much the language has evolved since then). The only reason I’ve ha…

Java has changed a great deal since 1.6, and includes something like first-class functions. But Java's main benefit over python is the JVM itself, which is extremely well specified and generally a rock-solid piece of kit. Python doesn't have a specification, or alternative implementations (AFAIK) and I think that hurts it.

Python is not specified but CPython serves as a reference implementation. Python has _numerous_ alternative implementations. Jython in Java, IronPython in C#, PyPy in Python (kinda...), and even more lesser-known implementations.

Re: Reasons Python Sucks

#343

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…

[deleted]

Re: Reasons Python Sucks

#344

Earlier quoted context omitted.

It's not a beginner language, but it is beginner-friendly. It's actually a huge problem if you end up trying to hire people to build enterprise software in Python, because everyone and their mother has "5 years of Python experience", but "scripting on your own" is miles apart from "building well designed systems".

What would you consider a beginner language then?

I would chose C due to its simplicity and ubiquity.

Re: Reasons Python Sucks

#345

Earlier quoted context omitted.

To a significant extent, it has. The article assumes you will use distro packages for the language, and pip for installing libraries. And that used to be standard practice. Today, if you are interested in a reproducible build environment, you will use pyenv to locally install an interpreter and stdlib, and pipenv to locally (to your project) install libraries and dependencies.

I would argue that for most projects (for most of my projects, anyway), this is still a sensible default. Except you should probably still be using distro packages for major libraries too. Consider; the reason for installing dependencies locally to your project is that it allows you to be precise about what library version you want. For example in Rust, we have Cargo.toml and I can have dependencies like primal = "0.…

Note that that will select any version in the 0.2.x range, not exactly 0.2.0. This is the range of versions that are interface compatible. If there’s a security release for the 0.2.x line it will pick it up. (Though you have to run “cargo update” in your project, though there are also tools to tell you if and when you need to do this for security issues.)

Re: Reasons Python Sucks

#346
post #177
post #114

Earlier quoted context omitted.

Not to mention, who hits the spacebar four times for their indentation? Actually. Do people do that?

I frequently have to when copy/pasting code in VS Code and it assumes the wrong indentation level.

You could select the whole pasted part and press tab or shift+tab to change its indentation level.

Re: Reasons Python Sucks

#347
> Inevitably, the discussion will turn to programming languages. One might lament "I have to modify some Java code. I hate Java. (Oh, sorry, Kyle.)" (It probably doesn't help that we gave Kyle the nickname "Java-boy" over a decade ago.)

This circle of "friends" sounds like a toxic environment where apologies are empty and contempt runs rampant.

Are they truly sorry for what they said, or are they sorry they said it to Kyle's face?

Re: Reasons Python Sucks

#348

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.

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 great package managers Python could learn from to make pip not suck. How is there not a standard way/built in lock system, or even a single standard package manifest (Gemfile, package.json, cargo.toml, mix.exs, or even composer.json) — which all (except maybe composer, it’s the one I’m least familiar with) are supported by default by the language, and have version locking.

I know pythons big thing is backwards compatibility, and breaking things is almost the biggest sin in that community (python2...), and maybe I’m ignorant, but I just don’t see how implementing a single standard package manager with a standard manifest and lockfile would break anybodies anything. All they have to do is make it so pip still works without it, and if they want to see how to do that, just look at NPM, who before this year was notorious for errant package versions due to the lack of lockfiles, but now they have it and I think pretty much everyone was happy about it. They literally could just port bundler to Python and call it a day, the code is open source, they can look at how it works, and it’s one of the most well regarded package managers out there, I’ve maybe run into 2 issues ever with it. The only other package manager I see get more praise is cargo, which they could (should) also look at for inspiration.

I know things have been improving. When I was using Python daily, the standard was still punching in some incantations to start of Virtual Env (which still confuses the hell out of me to this day) and piping the contents of a requirements.txt file into pip (with I think at least some level of version locking). But, from what I’ve gathered is there are some solutions being built to bring pip out of the early 2000s, but they’re quite fragmented efforts, and they all fall short in different places.

Python is a great language, pip and all the bullshit that comes with it is terrible.

Re: Reasons Python Sucks

#349

A better reason to hate Python: the internal model is way overcomplicated for what it's meant to be: a beginner-friendly scripting language. "Everything-is-an-object", duck typing, decorators, bizarre scoping rules, etc., all make it difficult for experienced programmers to understand, let along beginners. I've always thought there's a much simpler language struggling to get out of Python, and I wish it would and wou…

> I've always thought there's a much simpler language struggling to get out of Python I agree, although I suspect we have different ideas as to which parts of Python would be included in that simpler language. For example, I quite like the consistency of "everything-is-an-object". FWIW some of the Python core developers have started to express a similar sentiment. Especially in the last few versions, where Python has…

Sure:

  >>> [[x*y for y in xrange(1,5)] for x in xrange(1,5)]
  [[1, 2, 3, 4], [2, 4, 6, 8], [3, 6, 9, 12], [4, 8, 12, 16]]
  >>> list([x*y for y in xrange(1,5)] for x in xrange(1,5))
  [[1, 2, 3, 4], [2, 4, 6, 8], [3, 6, 9, 12], [4, 8, 12, 16]]
  >>> [list(l) for l in ((x*y for y in xrange(1,5)) for x in xrange(1,5))]
  [[1, 2, 3, 4], [2, 4, 6, 8], [3, 6, 9, 12], [4, 8, 12, 16]]
  >>> [list(l) for l in [(x*y for y in xrange(1,5)) for x in xrange(1,5)]]
  [[4, 8, 12, 16], [4, 8, 12, 16], [4, 8, 12, 16], [4, 8, 12, 16]]
The problem is that the `x` in the inner comprehension gets somehow linked to the variable `x` in the outer comprehension, rather that the value of `x`. (This matches Python's similarly bizarre closure semantics.) So, the results are "as expected" when either (a) the inner comprehension is evaluated eagerly (first and second example), or (b) the outer comprehension is evaluated lazily (second and third examples). But if both the inner and outer comprehensions are evaluated lazily, the inner comprehensions just see whatever the "last" value of `x` was, which I think to many people is surprising. (No less so than mutable default arguments, at least.)

Re: Reasons Python Sucks

#350
Well, I do think Python sucks but those reasons have relatively little to do with it to me. I just don't like it from an engineering point of view.

- lack of proper typing - it pretends to have a type system but hardly enforces it anywhere at least with any of the common practices used by the community. 'quacks like a duck' is a completely asinine excuse for not properly using types and interfaces.

- lack of true multithreading (aka, GIL): if you can't use all the cores on your computer you drastically limit the scope of applications that can be implemented. No, I don't want to restructure my application into a distributed multiprocessing system just to access the basic capabilities of the CPU in my computer thanks.

- lack of true cross-platform. partly because of the previous point half of Python's ecosystem is written in C and needs to be compiled for (if not on) the target platform. Python tries to pass as a language with Java-like bytecode but the reality is it doesn't even come close to that. We regularly try to install Python tools and find that they can't run because some obscure shared library isn't available on our system, etc.

Mostly, I dislike Python because it seems to be such a trap for new programmers who learn programming in it and then think they should never have to learn anything else. Trying to coach people on my team who started with Python to use or learn anything else is extraordinarily difficult. I remember when Java was like that and it was ugly then - it's just as bad if not worse with Python.

Post reply on HN