Reasons Python Sucks • Hacker News Board

Re: Reasons Python Sucks

#551

Post by L0stLink » Fri, Dec 21, 2018, 6:16 AM UTC

vorg wrote: post #539

L0stLink wrote: post #467

Earlier quoted context omitted.

I do not see your comment as fair to the parent: > there are umpteen alternatives (gradle etc) there was ant (build tool) then came maven which is much more flexible and contains dependency management capabilities (and _is loved_ by many) nothing to add that the parent did not already say. Then came gradle which has faster build speed and features like incremental builds and a Groovy based configuration. pip did not…

> Then came gradle which has faster build speed and features like incremental builds and a Groovy based configuration You make it sound like adding Apache Groovy for configuration to a build system is an improvement. When build systems with a declarative config language, such as make, ant, and maven, replace procedural build scripts, that's the improvement . Using a procedural language like Groovy instead is a large…

I agree, my above comment was aimed at this part of the parent comment:

> a huge and over-complicated xml-based system

It was an attempt to show that there are not 'umpteen different alternatives' and the ones that exist, do so for a reason. Though looking back, I should have worded it in a better way.

Re: Reasons Python Sucks

#552

Post by ric2b » Fri, Dec 21, 2018, 5:32 PM UTC

jrs95 wrote: post #530

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.

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.

There's pipenv now, which wraps pip and venv to do all that in a super simple way.

It has some performance issues but it's still quite a recent project.

Re: Reasons Python Sucks

#553

Post by ric2b » Fri, Dec 21, 2018, 5:40 PM UTC

bakery2k wrote: post #307

earenndil wrote: post #275

Earlier quoted context omitted.

Type annotations don't seem to actually have any effect, though? Consider: >>> def add(a: int, b: int): ... return a+b ... >>> add("a", "b") 'ab' This should be an error, even if it's a runtime error.

There doesn't seem to be any interest in checking type annotations at run-time. Unfortunately, without doing so, type annotations look authoritative but are essentially just comments. I believe Julia is an example of a dynamically-typed language which does perform such checks at run-time - including as part of its support for multiple dispatch.

Python has a "we're all adults here" mindset, which means it will allow you to reach into internals of libraries, ignore type hints, etc because maybe you actually know what you're doing and know the drawbacks but just need a quick solution (lots of python code is small throwaway scripts).

For actual projects you can use a static type checker like mypy.

Re: Reasons Python Sucks

#554

Post by sam0x17 » Tue, Dec 25, 2018, 5:03 AM UTC

MR4D wrote: post #269

NoGravitas wrote: post #258

Earlier quoted context omitted.

To a significant extent, it has. The article assumes you will use distro packages for the language, and pip for installing libraries. And that used to be standard practice. Today, if you are interested in a reproducible build environment, you will use pyenv to locally install an interpreter and stdlib, and pipenv to locally (to your project) install libraries and dependencies.

In my mind, creating a Python 4 that would be a consolidation of all of these things under one release umbrella (or at least a major release), so that things could be synchronized would be a good way to handle this. Right now, things are all over the place, and things that used to work 5 years ago still kindof work, rather than either working or failing. And it's that "partial working" that really gets developers tic…

I agree. imo python has been steadily falling behind ever since the 2x/3x split.