Hacker News new | ask | show | jobs
by zetalyrae 1082 days ago
I noticed this the other day while writing a small server in Python. FastAPI is 0.100, fine. But I was surprised to find:

- Uvicorn is 0.22

- httpx is 0.24

- starlette is 0.28

And so on and on. More generally, the quality of Python's tooling and ecosystem is astonishingly low compared to the investment that every day pours into it.

3 comments

How on earth do people get from "the version number starts with a zero" to "the quality is astonishingly low"? It blows my mind.

Edit to add: If I was an opensource package maintainer again, my first action would be to massively bump the major version number of my packages. HUGE increase in quality right there.

Not the actual quality but I suspect the perception of quality by some people would genuinely be increased by bumping the version numbers. Maybe it would help with adoption.
In SemVer, having the first number be zero means that the project is still in unstable development.
Are those libraries actually not production ready as might be implied by the 0.x or are they just not willing to bump to 1.x for whatever reason? A lot of the projections mentioned in the submission seem to be production ready despite the version number.
"Production-ready" is a state of mind.

They are widely used in production. Maybe some of them are de-facto production ready. But the developers don't want to make commitments to API stability.

And Python being Python it is very hard to statically enforce that you're upholding SemVer promises.

Only you can decide whether something is production-ready for you. The library author doesn't know what you're trying to do so they can't possibly know whether their library is ready to be used in your production. You could be making an experiment that's going to form part of a payload for a rocket, an embedded device that gets surgically-implanted into people, is life-critical and very hard to update or you could be making an online meme generator. Production-ready really does mean completely different things in these cases.
Astonishingly low compared to what? And in what aspects? (Asking unironically.)
I use Rust professionally and even though it is a newer language with infinitely fewer developers and sponsoring organizations, the tooling and ecosystem is already superior. `cargo` is superior (in DX terms) to whatever nightmare is current in the Python world, `rust-analyzer` is better than to PyCharm, the ecosystem is smaller but more reliable.
I regularly hear that the tooling of Python is bad, but we've had Poetry for a while now and it just works.

Unfortunately, I'm not experienced in Rust so I cannot really compare it to cargo. However, Poetry does everything I would expect from dependency management and packaging/publishing and I've never had problems with it.

Also, there is ruff [2] (ironically written in Rust) and mypy [3] (they recently left 0ver!) for static analysis, black for code formatting (I really miss an opinionated formatter like this in other languages), etc. They also work just fine. Python tooling doesn't seem bad to me.

[1] https://python-poetry.org/ [2] https://github.com/astral-sh/ruff [3] https://mypy-lang.org/

I'll grant it could be much worse (Common Lisp, OCaml also have significant tooling problems). I haven't used mypy but I do use pyright and it's alright.

The only way I've found to make Python tolerable is 1) lots of dataclasses and 2) using it as a more strongly-typed bash (i.e.: not for building large and complex software objects).

Poetry works, but unfortunately it depends on Python and so it frequently breaks unless you’re very careful with your Python environment management.

Installed it with your system’s native version? Good luck getting it to spawn a venv in a newer version. Used a Homebrew version? When it updates, Poetry breaks. Using asdf? Everything breaks, somehow.

I recently tried pipx and have hope that this will persist.

True, that's why they recommend installing Poetry either via their installer or using pipx, as you did.

pipx and pip's externally-managed-environment should help mitigate a lot of the broken environment issues. I use them too.

There is a new generation of Python tooling that is very high quality.

`rye` is the equivalent of `cargo`

`ruff` is the equivalent of `clippy`

Both are single-purpose, highly-functional and blazingly fast. Both written in rust actually :)

Throwing out the unpopular opinion here: PHP! For all the hate it gets, the package ecosystem is really great. Libraries follow Semver (because the package manager, composer, requires it), quality is usually high, even for less widely used packages, and compatibility is taken seriously.