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

41–50 of 554 posts

Re: Reasons Python Sucks

#41

Post by colanderman »

alexhutcheson wrote: post #36
colanderman wrote: post #11

Earlier quoted context omitted.

Python (and Java) do not pass anything by reference. They pass by pointer-value. (If they passed by reference, you could change to which value a caller's variable was bound, like you can in C++).

> (If they passed by reference, you could change to which value a caller's variable was bound, like you can in C++) I might be misunderstanding you, but I don't think you can do this in C++. References can't be changed to point to a different object after initialization. If you have code like: void MyFunc(Foo& ref_param) { Foo new_foo; ref_param = new_foo; } The assignment above isn't "changing the value to which a c…

The proper analogy for a Python object is `std::shared_ptr`: in Python, all "objects" are actually reference-counted pointers to objects (thus making them shareable). And then yes, in C++, you can change to which object the caller's "object" (pointer-to-object) points to, if you pass a reference to that. This is not possible in Python: all you can do is pass that shared-pointer value around, not the value of the object itself, nor a reference to the shared pointer.

This is a well-known distinction that goes by several names, see e.g. https://en.m.wikipedia.org/wiki/Evaluation_strategy#Call_by_...

Re: Reasons Python Sucks

#42

Post by jbarberu »

MichaelMoser123 wrote: post #7

the self argument for methods/method calls is stressful (having to define self for methods and having to call a method via self); also the fact that you need to check if dictionary key exists, else you get an exception when trying to get the keys value. Also ':' at the end of each line. I always forget at least one of these. You didn't have any of these goodies in good old perl (sob, sob) (wow, this one got flagged p…

"also the fact that you need to check if dictionary key exists, else you get an exception when trying to get the keys value."

dictionary.get(...) is specifically for avoiding the exception, you should just get None if the key doesn't exist. Unless I'm misunderstanding you and your complaint lies elsewhere.

Don't get me wrong, there are plenty of things that are stupid/annoying with python, this comment however reads more like "python is bad because I can't write perl in it". I think that's why people are flagging it.

Re: Reasons Python Sucks

#43

Post by Symmetry »

superasn wrote: post #19

I too have tried it many times mainly because of all the great ML libs for python but each time I dreaded using it for Reason #3 (Syntax). Using indents for blocks just seemed unintuitive and error prone to me. But I dismissed it because all the programming languages I've worked with have had curly braces so maybe the reason for my discomfort was that it was unfamiliar.

Most languages that use braces also encourage you to indent the things enclosed by the braces to make it easier to read. However, people sometimes make mistakes. For instance I've seen this quite a number of times

  if (a) 
    somestatement;
    someotherstatement;
  athirdstatement;
Which is of course horribly misleading unless you're careful because the second statement isn't actually conditional on a. Python forces the indent to match the semantics.

Re: Reasons Python Sucks

#45

Post by alexhutcheson »

colanderman wrote: post #41
alexhutcheson wrote: post #36

Earlier quoted context omitted.

> (If they passed by reference, you could change to which value a caller's variable was bound, like you can in C++) I might be misunderstanding you, but I don't think you can do this in C++. References can't be changed to point to a different object after initialization. If you have code like: void MyFunc(Foo& ref_param) { Foo new_foo; ref_param = new_foo; } The assignment above isn't "changing the value to which a c…

The proper analogy for a Python object is `std::shared_ptr `: in Python, all "objects" are actually reference-counted pointers to objects (thus making them shareable). And then yes, in C++, you can change to which object the caller's "object" (pointer-to-object) points to, if you pass a reference to that. This is not possible in Python: all you can do is pass that shared-pointer value around, not the value of the obj…

Ah, got it. Your basic point is that C++ params can use two layers of indirection (pointer-to-ref, ref-to-pointer, pointer-to-pointer, etc.), while doing so in Python is clunky. Makes sense.

Re: Reasons Python Sucks

#46

Post by berdon »

I agree with the OPs points but disagree with the degree to which the author has used them as a means to "hate" a language. I generally avoid Python too but saying you hate the language because of a bunch of contrivances mostly wrought from inexperience and holding too strongly to C like languages is poor form.

Versions: Ok? Versioning and fragmentation is a hard problem. Backwards compatibility is a hard problem. Moving fast and never breaking anything is a nearly impossible problem. Python sucks at it, lots of things suck at it. There are many examples of other languages (.NET Core, for example), platforms, frameworks, etc that all suffer from this. It can be a reason to avoid those things but probably not one to base a loathing on.

Also, lots of people still use Perl. Lots of people still love Perl. I don't know why.

Installation: This screams "windows only" user. Path'ing, local dependencies, and package management is relatively common and you should force yourself to be comfortable with those concepts. Just saying "I should be able to just run one thing and be done forever", albeit ideal, is naive and never going to happen.

Syntax: Yep. Spacing blows and you're always going to have stupid issues with it. I hate Python's spacing. Someone ought to create a custom interpreter that allows for using braces.

Includes: Most of these complaints sound like they're coming from someone largely silo'd in the C/C++ world of wanting to know everything. "With C, you can just look in /usr/include/*.h" - the author is admitting he's unhappy because Python isn't C.

Quirks: General complaints about other languages... and using those complaints to somehow sour Python? The quirks he does list for Python aren't even strange - they're pretty useful.

Local Names: OP probably could have just included this in quirks rather than having another point. I'm pretty sure there's actually a means of avoiding this type of import issue by some silly Python pathing shenanigans.

Re: Reasons Python Sucks

#47

Post by peterwwillis »

This rant would have been exactly the same if he had just discovered Perl5. It's got way more quirks than Python, but you deal with it, because the language is super useful.

The one valid gripe that wasn't quite there is why doesn't Python (or any other language really) manage its modules like CPAN? CPAN is amazing. It's ancient and dusty and missing obvious modern improvements, but it's still way more useful than anything else.

Searching through PyPi is pretty awful. Look for "yaml versioning" and get 10,000 projects to wade through. CPAN is hierarchial, so not only can I find what I'm looking for, it even exists on disk where I expect it.

Because of all that, a few other things happen. The low level modules are older, exposed to more users, so people find them first, improve them over time, and this influences and improves new code. Not only are there these great examples of quality code for comparison, but code reuse and extending is way more common than entirely new modules.

Testing is also really rigorous. CPAN testers framework tests across all Perl releases and computing platforms, continuously. Perl module build instructions are converted easily to Makefiles, making it easier to build and test on other platforms if you're not familiar with Perl conventions.

Most modules also provide real in-line documentation, not just one line describing what a function does. Perldoc usually gives you a real man page for any given module you're looking at, whereas Pydoc gives you a bare list of method calls and objects that maybe the author added documentation to, but often not. Which am I supposed to use, for what? Might as well go read all the code...

...oh, and unrelated, but using regex's in Python is kind of horrifying.

Re: Reasons Python Sucks

#48

Post by woodrowbarlow »

> if I'm testing a screen capture program with a C library called "libscreencapture.so", i would call my program "screencapture.c" and compile into "screencapture.exe"

author must be running an unusual OS.

Re: Reasons Python Sucks

#49

Post by int0x80 »

sidcool wrote: post #5

Interesting points. I disagree with Reason 2 though. Python has smoother installation than Java and GCC. One of the reasons Python is popular is because it's easy to do a lot of things. Some python choices don't make sense technically, but they were made to make python as easy as possible. Performance was never the first criteria of Python (or ruby). My personal peeve is with mandatory indentation. But again, that's…

>Python has smoother installation than Java and GCC

How so? With java you can get your distro version from the package manager or just download a tarball and setup your PATH. Maybe install maven. GCC and build deps is as simple as a xxx install build-essential/build-base and you have a C compiler for C89/C99/C11.

Re: Reasons Python Sucks

#50

Post by Symmetry »

I agree with a number of these but I really don't understand #4. If you want to know what's in a module then 'import foo; help(foo)' in your interpreter will give you it. In C you can't just grep /usr/include because you might be importing form somewhere else.

And in C everything goes directly into your main namespace, the equivalent of 'form foo import *'. And even with single letter renames you can just quickly check at the top of the file for what the rename is, 'gg' in vim and probably similarly easy in most people's editors. And really importing common libraries as single letters should be by convention in a codebase.

I really think that Python's import story is one of my favorite things about the language and it's something where I'm often comparing other languages to Python and finding that they're coming up short.

Post reply on HN