Reasons Python Sucks • Hacker News Board

Re: Reasons Python Sucks

#61

Post by teddyh » Tue, Dec 18, 2018, 3:39 PM UTC

Felz wrote: post #39

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…

It's been a while since I touched Python (thankfully), but there's also: - The hideous __method__ and _private conventions - A friend of mine was complaining about the implicit string concatenation: ["foo" "bar", "baz"] whoops forgot a comma and now there's a very hard to find bug - pyc and pyo files littering the filesystem after running (yes, only a minor nuisance) - import anywhere, the ugly __name__ = "main" hack…

> implicit string concatenation

C and many other languages had that before Python, and it’s very useful to be able to split a single string over many lines in your source code. Python very wisely also implemented this feature.

> - pyc and pyo files littering the filesystem after running

Fixed in Python 3.

Re: Reasons Python Sucks

#62

Post by graycrow » Tue, Dec 18, 2018, 3:41 PM UTC

porpoisely wrote: post #33

CurtHagenlocher wrote: post #3

A number of these points seem like reasonable opinions to have. But two which had me questioning the breadth of the author's experience were "Most programming languages pass function parameters by value." and "In every other language, arrays are called 'arrays'. In Python, they are called 'lists'." To the author: 1. Java, JavaScript and C# all have types which are passed by reference. (They also have types which are…

In C#, all variables ( reference or value types ) are passed by value. Yes, even reference types are passed by value. If you want to pass variables by reference, you need to use special modifiers ( out or ref ).

Yes, but for a reference types that value IS a reference, so if you change a complex type, that change will persist after return to the calling code.

Re: Reasons Python Sucks

#63

Post by camjohnson26 » Tue, Dec 18, 2018, 3:41 PM UTC

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…

I think the huge volume of 3rd party libraries that Javascript and Python have show that prioritizing developer experience over technical perfection leads to a more useful language. I hate Python's quirks but it's the first language I reach for if I'm just fetching data from an api or doing some web scraping. It's so fast and expressive that it makes up for the negative parts of the language.

Re: Reasons Python Sucks

#64

Post by rciorba » Tue, Dec 18, 2018, 3:45 PM UTC

colanderman wrote: post #35

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…

> Take lists: some operations are methods, some are functions, some mutate the list, some make a copy, some are global, some are in a module.

Let's take the list type, the public methods are: 'clear', 'copy', 'count', 'extend', 'index', 'insert', 'pop', 'remove', 'reverse', 'sort'

Obviously as the names imply `copy` returns a new list, and `count` returns an integer. Neither mutate the list.

For the rest of it: methods mutate the list. There are some builtin functions that do similar things, but those always a new object (sorted, reversed)

Re: Reasons Python Sucks

#65

Post by smt88 » Tue, Dec 18, 2018, 3:46 PM UTC

I'm flagging this not because I disagree, but because there's nothing new or insightful in the article and the headline is just flamewar bait.

I'd love to see a deep dive from an expert on why Python sucks, because I truly hate Python, but this isn't it.

Re: Reasons Python Sucks

#66

Post by int_19h » Tue, Dec 18, 2018, 3:50 PM UTC

colanderman wrote: post #35

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…

A great "simple beginner language" would be Lua, if only it had a decent standard library.

Re: Reasons Python Sucks

#67

Post by ApolloFortyNine » Tue, Dec 18, 2018, 3:50 PM UTC

>By the same means, Python has distinct silos of code for each version. And the community keeps dragging along the old versions. So you end up with a lot of old, dead Python code that keeps getting dragged along because nobody wants to spend the time porting it to the latest version. As far as I can tell, nobody creates new code for Python2, but we drag it along because nobody's ported the needed code to Python3.x. At the official Python web site, their documentation is actively maintained and available for Python 2.7, 3.5, 3.6, and 3.7 -- because they can't decide to give up on the old code. Python is like the zombie of programming languages -- the dead just keep walking on.

I think I could make a comment on every one of this authors 'gripes' but I'll just do one for now.

Does this author think a minor version update should immediately EOL the previous version (3.5,3.6)? And obviously this author never heard that Python 2.7 is EOL 2020 [1]. But you know just reading this author's problems that if Python 2.7 had been EOL right after 3 released, or if a minor version upgrade immediately EOLs the previous minor versions (seriously, how is this a complaint?) he'd be posting about that instead of these 'which version do I choose' issues.

I just honestly can't believe a developer would complain about maintaining code for 'too long'.

[1] https://legacy.python.org/dev/peps/pep-0373/

Re: Reasons Python Sucks

#68

Post by cschmidt » Tue, Dec 18, 2018, 3:51 PM UTC

qntty wrote: post #59

colanderman wrote: post #35

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…

Is python really meant to be a beginner-friendly language? I tend to think of it as lisp-without-parens, and lisp is not very beginner friendly.

It is usually the "first language" of choice these days, when teaching programming.

Re: Reasons Python Sucks

#69

Post by nicodjimenez » Tue, Dec 18, 2018, 3:52 PM UTC

For scripting, there's nothing better than Python (that I know of).

Re: Reasons Python Sucks

#70

Post by notacoward » Tue, Dec 18, 2018, 3:52 PM UTC

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 (syntax) seems to be about not supporting the author's own highly idiosyncratic habits, which include deep nesting and putting debug code in the first column (ugh). The result actually seems better for maintainability than the author's own unconstrained code would be.

4 (includes) is in the "exactly wrong" category. Includes as in C/C++ are a horrible way to handle module interfaces. Really, just about the worst option available. Modules are far better, and if the author hates the fact that importing a module might run initialization code wait until s/he finds out about constructors (including __init__ and __attribute__((constructor)) even in C).

5 (nomenclature) is also a bit insane. Lists aren't called arrays in Python because they're not arrays. Next!

6 (quirks) criticizes quote handling in Python, but mentions bash's quote handling without a word of comment about how that's even worse. Different languages have different quoting conventions. Python's might not be perfect, but many are far worse. Get over it.

7 (pass by reference) is another totally-wrong one. Passing by value is not the universal norm in other languages, and it's not even clear what it means sometimes because of deep vs. shallow copies. Passing by reference is almost certainly better for efficiency, and often for correctness as well when copies becoming inconsistent with each other is a concern. I'd rather have pass-by-reference as the default, and have to work to make copies, than the other way around.

8 (local names) barely even make sense. Shadowing names, whether of variables or of modules/libraries, is a bad idea anyway. If you want the library and the program not to have the same name, use a prefix for each role. Expecting the language to handle this for you is just asking for trouble.