Reasons Python Sucks • Hacker News Board

Re: Reasons Python Sucks

#521

Post by qwerty456127 » Wed, Dec 19, 2018, 10:30 AM UTC

Looks more like a proof Python is near-perfect to me. Because they've tried to write a list of what's wrong with Python and failed to name a single real problem/quirk you even have to know about. I've seen lists illustrating how JavaScript, PHP, C++ and other languages are bad and they all made me feel like "that's so crazy I will never code this language!" but this list for Python is just "pff... will you name a single thing that is not a minor inconvenience?".

The only thing that really annoys me about Python as a language (and it still is just an inconvenience and a matter of taste) is the file=module thing, I want to split a module into a number of files so I could define every class in a separate file without having to import every one from a separate module then, C# namespace model feels a way better. I would also love to see 1-st class support for type enforcing (i.e. if I define a "type hint" and a value fails to comply to it should raise a warning) and support for immutable variables (that can only be assigned once). Using 4 spaces per indentation level indeed sucks (I would prefer 2 spaces) but this is not a language problem and its seriousness is futlie.

Re: Reasons Python Sucks

#522

Post by lou1306 » Wed, Dec 19, 2018, 10:33 AM UTC

dontreact wrote: post #474

saagarjha wrote: post #455

Earlier quoted context omitted.

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?

IMO lambdas are useful because they reduce mental overhead by allowing the developer not to give names to trivial functions [1]. Compare these two equivalent pieces of code:

    youngest_person = min(people, key=lambda x: x.age)

    def get_age(x):
        return x.age
    youngest_person = min(people, key=get_age)

This may not seem like a huge difference, but using lambdas scales better.

[1] Incidentally, this is the same reason why I don't miss multi-line lambdas (in Python): multi-line functions are seldom trivial.

Re: Reasons Python Sucks

#523

Post by taejo » Wed, Dec 19, 2018, 10:53 AM UTC

kyralis wrote: post #489

lolc wrote: post #373

Earlier quoted context omitted.

Weird though when the author mentions the desire to rewrite Python functions in C. The whole section about references was very confused. Especially for someone who supposedly knows C.

I suspect the issue is precisely that he's coming from C. In C, pass by value vs pass by reference is extremely explicit. In python, it's "magical", because it depends entirely on the type of the variable that is passed in, which is itself hidden from view of the code due to the dynamically typed nature of the language. This has been one of my own annoyances with Python as well.

It doesn't depend on the type at all. Objects are never copied when passed (or assigned to names). The only thing that might give you the opposite impression is that some objects are immutable, so you wouldn't be able to notice if a copy were made (without calling `id`).

Re: Reasons Python Sucks

#524

Post by vram22 » Wed, Dec 19, 2018, 11:00 AM UTC

vram22 wrote: post #422

closed wrote: post #362

Earlier quoted context omitted.

It's worth noting the second can't be used inline. I don't know the history, but it seems like that might be one of the reasons `x() if y()` isn't allowed in python. [x() if y()] if it existed, might carry an explicit else None. On the other hand [x() and y()] does something different when y() is falsey.

>I don't know the history, but it seems like that might be one of the reasons `x() if y()` isn't allowed in python. Maybe I misunderstood your context, but if not, conditional expressions do exist in Python: $ python Python 2.7.12 |Anaconda 4.2.0 (32-bit)| (default, Jun 29 2016, 11:42:13) [MSC v.1500 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. Anaconda is brought to…

Sorry, the code shown in the two Python interpreter sessions above, is not a good example. To make the concept of conditional expressions more clear, this example is better:

  >>> from __future__ import print_function
  >>> for i in range(3, 5):
  ...     print(i, "is", "odd" if i % 2 == 1 else "even")
  ...
  3 is odd
  4 is even

which can be shortened to this:

  >>> for i in range(3, 5):
  ...     print(i, "is", "odd" if i % 2 else "even")
  ...
  3 is odd
  4 is even

Now print() is printing 3 values: i, "is", and either "odd" or "even" based on the boolean condition.

That works in both Python 2 and 3.

Re: Reasons Python Sucks

#525

Post by profalseidol » Wed, Dec 19, 2018, 11:01 AM UTC

AlphaSite wrote: post #510

zbentley wrote: post #483

Earlier quoted context omitted.

> I've never used maven so I don't know if it is better or worse It's about the same for packages with a native component. Local build tools are still needed. Java stuff is slightly less likely to have a compiled component in the first place, in my entirely subjective impression. Maybe that's because of convention, or performance; I don't know. But when a compiled dependency does exist, and nobody included a prebuilt…

I’ve always found thinks like LWJGL tricker than pyglet etc.

That's because LWJGL is complicated just like DirectX is. It uses low level API that calls native C code. It aims to give you a thin Java API layer above OpenGL, Vulcan, controllers, audio, etc.

https://en.wikipedia.org/wiki/Lightweight_Java_Game_Library

Whereas pyglet, seems to me like a high-level regular game engine that includes a widget library.

Re: Reasons Python Sucks

#526

Post by blattimwind » Wed, Dec 19, 2018, 11:21 AM UTC

cutety wrote: post #473

laughingbovine wrote: post #361

Earlier quoted context omitted.

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/l…

requirements.txt is a lock file, generated by pip freeze, which defines the exact version of all packages in the current environment.

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

It is.

Re: Reasons Python Sucks

#527

Post by blattimwind » Wed, Dec 19, 2018, 11:23 AM UTC

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…

Ah, you see, you actually only know second-generation packaging. "pip and all the bullshit [i.e. virtual envs, setuptools]" is actually what has been developed to address issues in the older distutils (and easy_install) tooling, and are fairly recent additions to Python. Buildout comes from the same era (~2005ish and was built on very different principles; it's still used in some niches.

Re: Reasons Python Sucks

#528

Post by SilverSlash » Wed, Dec 19, 2018, 11:38 AM UTC

How does this garbage make it to the front page of HN?

Re: Reasons Python Sucks

#529

Post by SilverSlash » Wed, Dec 19, 2018, 11:43 AM UTC

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…

A list of well informed and articulated concerns about python probably wouldn't be titled "Reasons Python Sucks".

Re: Reasons Python Sucks

#530

Post by jrs95 » Wed, Dec 19, 2018, 12:14 PM UTC

toyg wrote: post #427

lmm wrote: post #390

Earlier quoted context omitted.

> 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? The Java module experience is miles ahead of the Pytho…

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

There's a lot I don't like about Maven, but its a vastly better solution than pip. Support for dev dependencies and no need to manage virtual environments more than makes up for its complexity.