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

481–490 of 554 posts

Re: Reasons Python Sucks

#481

Post by Lazare »

About 1/4 are valid, important criticisms, another 1/4 are technically true but quite trivial (and are mostly caused by his very idiosyncratic coding habits), and 1/2 are just howlingly wrong, mostly in that order. A decent chunk of the actually correct ones seems to boil down to "C does it differently", which well...if that's you're yard stick, you're going to be pretty busy criticising other languages.

I've got to call out his point 7 in particular; it's so wrong it kind of makes me wonder what he was trying to say. He's calling out Python for not following a convention that doesn't exist, nobody else follows, couldn't even work, and which you wouldn't even want. What in the world?

Re: Reasons Python Sucks

#482

Post by cat199 »

twunde wrote: post #375
_ea1k wrote: post #206

Earlier quoted context omitted.

I get your point, but do those other languages not often have differing versions available as well? Its equally possible to install many different major and minor versions of Java, for example. And I regularly run into issues with people using non-distribution Java packages that don't really integrate as well with the OS as the packaged one would. I feel like some of his complaints about the ecosystem there were real…

Yes, other languages have the ability to have multiple differing versions as well BUT the big difference is that most have a relatively easy and well-known way to install and set up the environment. In Ruby, if you wanted to run multiple versions of ruby on the same machine, you'd use RVM. Python is particularly hard to set up the environment for. I'd rather set up the environment for Ruby, PHP, Node or Perl than Pyt…

> PHP

really?

which way?

embedded? fastcgi native? slowcgi? fpm? cli?

natively managed or via process control?

which process control?

which ini file is configured for which application again?

are my suexec/whatever wrappers working?

if not, which user/group/permission N levels up is causing the issue?

which bytecode cache to use? is that working properly?

why aren't my URL rewrites working properly?

Re: Reasons Python Sucks

#483

Post by zbentley »

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…

> 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 chunk of binary for your architecture in the jar, a build is needed in roughly an equivalent fashion to what pip (or npm, cpan(1), etc.) do.

Re: Reasons Python Sucks

#484

Post by mark-r »

Lazare wrote: post #481

About 1/4 are valid, important criticisms, another 1/4 are technically true but quite trivial (and are mostly caused by his very idiosyncratic coding habits), and 1/2 are just howlingly wrong, mostly in that order. A decent chunk of the actually correct ones seems to boil down to "C does it differently", which well...if that's you're yard stick, you're going to be pretty busy criticising other languages. I've got to…

Point 7 is only relevant because it leads to behavior that's not intuitively obvious. If you reassign an object in a function then it's not visible outside the function, but if you modify the object it is. That's a very subtle distinction.

Re: Reasons Python Sucks

#485

Post by cat199 »

sam0x17 wrote: post #211
notacoward wrote: post #70

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…

> 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. Regarding 1: I'm sick of people saying that the ecosystem != the language. No one is going to…

> No one is going to be able to prop up an alternative ecosystem and get more traction than the language's own ecosystem

node vs web browser? linux vs unix? ubuntu vs debian? autotools vs base make?

i'm sure these aren't the best examples.

irrespective, you can (like|dislake) the language and (like|dislike) the ecosystem separately.

"oh I hate programming in XYZ it's far too verbose but it really does have a nice package management system"

yes, they are connected, but I don't criticize a hamburger by complaining about the taste of my soda..

Re: Reasons Python Sucks

#487

Post by dbcurtis »

nitely wrote: post #436
dbcurtis wrote: post #207

Earlier quoted context omitted.

> I wish python had some equivalent to the switch statement that didn't involve workarounds with dictionaries, because sometimes you just want a clean way to deal with a value that can take 7 different forms. I am with you there. I have often wished for a C-like switch(). That said, I think the best Python leans towards the functional, so instead of a switch(), it probably would be better to come up with some kind of…

The pythonic way is to do duck typing, meaning don't check the params types at all. Assertions are ok to check things that should never happen. But if you're gonna put them everywhere then better use type hints. I'd use TypeError on public APIs, for private APIs is as bad/good as assert.

What I describe is duck typing, with eager authentication of duck specie. Exceptions raised at point where the greatest clarity of error message is possible.

Aspirationally, anyway.

Re: Reasons Python Sucks

#489

Post by kyralis »

lolc wrote: post #373
com2kid wrote: post #311

Earlier quoted context omitted.

> Has the author never given a pointer as an argument to a function before? Possibly not, many devs now-days have never used a real native language.

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.

Re: Reasons Python Sucks

#490

Post by ubernostrum »

brudgers wrote: post #391
ubernostrum wrote: post #370

Earlier quoted context omitted.

probably needs written in C because built-in types are closed "Everything is an object" does not necessarily imply "all objects are always infinitely monkeypatchable at all times". It also doesn't necessarily imply "you can change how the parser interprets literals". You're also going to be really mad when you learn about __init_subclass__ and the fact that Python lets you write a class that can't be subclassed!

Python doesn't make me mad. It's frustrating because it's design never makes any sense to me. __init_subclass__ is a perfect example. Not at the level of what __init_subclass__ does. But that instead of implementing private methods, there's are rules around double underscore methods and double underscore methods have different behavior (name mangling). They don't actually make the method private, the actual name is n…

Mangling of double-underscore names isn't there to provide access control like in Java or C++.

Mangling of double-underscore names is explicitly documented as existing "to avoid name clashes of names with names defined by subclasses". The use case there is a parent class defines a method called, say, "foo". Other methods of the parent call self.foo(). Then a subclass overrides foo() but changes the signature (say, by adding a new non-optional argument), and doesn't override the other methods that call self.foo(). Without name mangling or something like it, this breaks. If the parent class either names the method "__foo" or aliases a copy of the parent class' implementation to "__foo", and calls self.__foo(), name mangling ensures those calls will find the right (as in, compatible) implementation of the method based on where the call came from.

That's it. That's the one and only use case for invoking name mangling in Python, and it's a thing that generally you shouldn't be doing anyway.

Name mangling also isn't invoked for leading + trailing double underscore -- a "__foo__()" method would not get mangled.

Post reply on HN