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

361–370 of 554 posts

Re: Reasons Python Sucks

#361

Post by laughingbovine »

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…

Maybe you haven't used it in a while but requirements.txt lets you specify packages and lock (or unlock) the version.

Re: Reasons Python Sucks

#362

Post by closed »

bakery2k wrote: post #132
closed wrote: post #116

Earlier quoted context omitted.

> I regularly wish python required some sort type indication for function parameters You can use type annotations, either via the builtin lib or 3rd party libs! https://docs.python.org/3/library/typing.html > do_x() if a.y() I feel this. You can use `a.y() and do_x()`, but I'm not sure how people would react :o

> `a.y() and do_x()` If you're happy to write it that way round, why not just use `if a.y(): do_x()`?

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.

Re: Reasons Python Sucks

#363

Post by mangodrunk »

heavyset_go wrote: post #208
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…

Came to a similar conclusion. I use Python a lot, and it certainly has its problems. However, the article's analysis doesn't even begin to scratch the surface of this topic in an informed manner. Instead, we're presented with paragraphs written by someone who can't read a stack trace: In [7]: def foo(): ...: print('foo') ...: print('bar') File " ", line 3 print('bar') ^ IndentationError: unexpected indent

Isn't that a strawman? Wouldn't a more apt example be:

    def foo():
        nums = [...]
        sum = 0
        for x in nums:
            print(x)
        sum += x
I don't know python well, but it seems like there could be subtle issues with indentation that wouldn't cause a compiler error, but would cause the wrong output.

Re: Reasons Python Sucks

#364

Post by ubernostrum »

fhood wrote: post #100
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…

It's funny how far off the author was, because there are genuine things to complain about with python, though they may not be exclusive to python. I regularly wish python required some sort type indication for function parameters, because dealing with libraries that take complex objects as function parameters can be an absolute nightmare. I wish python had some equivalent to the switch statement that didn't involve w…

I regularly wish python required some sort type indication for function parameters

As others pointed out, Python has optional type annotations and has had them since 3.0. They're static-only (you don't get runtime type checking from them), though, and getting what you want out of them will effectively require every single function, method and variable in not just your codebase but in every third-party dependency and all of their dependencies to be annotated.

Also, annotating "complex objects" tends to be an unreadable mess. If you have lots of functions which take complex objects as arguments, rather than a more clear list of parameters, that's probably not going to be solved by type annotations; it will be solved by rewriting the functions. In other words, you probably will not be helped by:

    def foo(o: HugeLongComplexTypeDefinition) -> OtherHugeLongComplexTypeDefinition
But you would be helped by:

    def foo(widget: Widget, operation: WidgetOperation, tolerance: float) -> Widget

Re: Reasons Python Sucks

#365

Post by jMyles »

mangodrunk wrote: post #363
heavyset_go wrote: post #208

Earlier quoted context omitted.

Came to a similar conclusion. I use Python a lot, and it certainly has its problems. However, the article's analysis doesn't even begin to scratch the surface of this topic in an informed manner. Instead, we're presented with paragraphs written by someone who can't read a stack trace: In [7]: def foo(): ...: print('foo') ...: print('bar') File " ", line 3 print('bar') ^ IndentationError: unexpected indent

Isn't that a strawman? Wouldn't a more apt example be: def foo(): nums = [...] sum = 0 for x in nums: print(x) sum += x I don't know python well, but it seems like there could be subtle issues with indentation that wouldn't cause a compiler error, but would cause the wrong output.

1) This is not the case that the author presented, though - it was specifically about 3 spaces instead of 4. This tells me that the author simply doesn't hang out with python people.

2) On the substance of your concern: I think the evidence is clear (although I'm aware of no study) that having both syntactical control characters (typical curlies) and style-only indentation is more likely to lead to the outcome that you present, because the eye will always gravitate to read by indentation, whether it's syntactical or not. So have the indentation be the syntax makes this problem more easily avoided, not less.

IE:

    def foo() {
        nums = [...]
        sum = 0
        for x in nums {
            print(x)
            }
            sum += x
        }

Re: Reasons Python Sucks

#366

Post by da_chicken »

toyg wrote: post #183
013a wrote: post #119

Earlier quoted context omitted.

> 1 (versions) and 2 (installation) have to do with the ecosystem, not the language. This argument really summarizes a beautiful and dangerous thing we see in the tech community far too often; you have a strong technical and scientific understanding of the system, but lack product and design thinking. You're right. Its a problem with the ecosystem, not the language. I'm still not going to use python because of the ec…

Note how almost all languages you take as shiny examples of virtue post-date Python: they all learnt from it so much , particularly on things like the stdlib. Python’s stdlib was the gold standard for a long, long time (the “batteries included” slogan was effective for a reason - they really were!). This was not by accident - Guido and others have always had the utmost care for good developer experience out of the bo…

> Note how almost all languages you take as shiny examples of virtue post-date Python

That's because Python is old. It's as old as Haskell. It's older than Java and JavaScript. It's older than the Borland Delphi and C++Builder IDEs. When Python was released, C++ was only 5 years old. Python is older than Linux. Rust and Go are both older than C++ was when Python was released. Hell, when Python was released, Perl was only 3 years old.

Further, Python's age doesn't mean that we can't or shouldn't criticize it. You shouldn't get a free pass on what you could do better just because you've done other things right. We should absolutely point to what doesn't work well and lobby for improvements even if they require significant overhauls. While, yes, Guido and company have worked very hard on developer experience out of the box, it would be really nice if someone would care about system administration and the long tail, too. It's great that your engineers love your tools, but someone still has to live in the homes that they build.

It's not like anybody here is shocked or confused when they hear people complain about Python versioning being a rats nest. I'd wager we've all experienced it at least once just like we used to have problems with multiple concurrent versions of the Java Runtime Environment being installed or other fun forms of dependency hell. If virtualenv or conda are such good solutions, why do so few projects seem to use them or deploy with them? If popularity or ubiquity are the measure of what's good in the ecosystem, doesn't that suggest that there's still a problem to be solved? A language should direct programmers to styles of system design that makes system management easy and clear, and Python does not do that at all. Is there a problem with complexity? Is there a problem with lack of education?

Re: Reasons Python Sucks

#367

Post by Karunamon »

pfranz wrote: post #265
riskable wrote: post #210

Earlier quoted context omitted.

I asked a "C all the things!" developer a while back why he hated Python's enforced indentation and in a whole lot of words he basically said that it makes it difficult to visually track scope when you have long chains of conditionals. The standard Python developer response to that is, "Aha! You like braces because they enable your bad programming practices !" However, I found the best way to illustrate that point is…

Isn't deep nesting (hence deep indentation) a sign of code smell? Yeah, you might end up shuffling the logic into a new file or a function that makes the file much longer, but I've noticed when doing that kind of refactoring it forces you to clean up the scoping quite a bit so there's less state to keep track of.

It depends on your definition of "deep".

Imagine an if, inside of a foreach, inside of a function definition, inside of a class. This is not terrible code, it's perfectly reasonable.

Now you're indented four levels in. Now combine this with some rather unreasonable and outdated assumptions that PEP8 (automatically enforced in many shops and OSS projects) has, like pretending that people are still on glass terminals and that anything longer than 79 characters is a problem. It also insists on four-space tabs, so this very simple construct has eaten 20% of your line budget.

..not to mention how it makes your code harder to read. I also share the author's concern about how you're less able to separate your debug code from your actual code.

Re: Reasons Python Sucks

#368

Post by ubernostrum »

cleandreams wrote: post #243

I'm a python hater. Yes it is easy, but in exactly the wrong way. Easy for simple code for middle schoolers. For grownups with large codebases to develop and maintain, it's not optimal. Of course I hate the whitespace trickery. I hate the auto formatting that sometimes doesn't work. Those are fairly minor. What I really, really hate is the lack of static typechecking. You often have to read lengthy swathes of code to…

Easy for simple code for middle schoolers. For grownups with large codebases to develop and maintain, it's not optimal.

Yes, like the tiny puny baby middle-school children who built microscopic useless toy "programs" (not even worthy of the name) at Instagram, YouTube, Dropbox...

What I really, really hate is the lack of static typechecking.

Then don't use dynamically-typed languages. Not everyone shares your tastes, nor do they have to.

And just as bad the fact it is impossible to encapsulate code.

The more you write here, the more I think C# is a great language for you. And I don't dislike C#! But you want a nice statically-typed object-oriented language with data hiding. C# is an example of one. Python is not.

And then the GIL!!

I've written at length about how the existence of the GIL is the result of tradeoffs that seemed perfectly reasonable at the time (keeping in mind that Python is older than Java, and I suspect older than the average HN commenter). With 20/20 hindsight would a different approach have been better? Sure, but if they'd had the ability to see the future in enough detail, the folks who chose those tradeoffs probably would have bought lottery tickets instead of building Python.

Re: Reasons Python Sucks

#369

Post by ubernostrum »

ezoe wrote: post #23

Reason 2 is getting out of hand for Python, Ruby, JavaScript, Haskell and OCaml. These so called package manager can't manage packages at all. I'd like to call it package downloader. They just download everything from language interpreter to library to a single directory and call it job done. No easy way to remove the package. The interpreter and library's version is forever fixed. Theoretically, it can upgrade the v…

No easy way to remove the package.

"pip uninstall" has been around as long as pip has.

Theoretically, it can upgrade the version but the user mostly don't.

In practice, people deploy to a virtualenv that gets recreated on each deployment, and tend to treat a virtualenv as an ephemeral thing.

Re: Reasons Python Sucks

#370

Post by ubernostrum »

brudgers wrote: post #224
civility wrote: post #188

Earlier quoted context omitted.

Are you after monkey patching, where you can add new methods outside of the class definition? That's not really a standard feature of all object orient languages - Java doesn't do that, for instance. Python integers are definitely objects: (3).real # returns 3 (3).imag # returns 0 Python's lexer/parser made different choices than Ruby's, so the parens are needed here.

In no particular order + Java doesn't promise "everything is an object." It has Base Types. + Python doesn't make a semantic promise that "everything is an object." Code for (3).fizzbuzz => "fizz" probably needs written in C because built-in types are closed and object literals use the built-in types. "3" cannot be forced to use a subclass of Integer. At the bottom, '3' is defined in terms of Types (i.e. "Built-in Ty…

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!

Post reply on HN