There is no such thing as an end user. Those folks who are on a smartphone playing a video game or watching youtube? And absolutely paying using a convenient digital payment method.

They are not us

Lets pray they die out quickly.

Python is a pile of interconnected packages, very rarely do they get woven into an end user facing app.

Instead we are interacting with packages. If the package doesn’t work: the maintainer is gone, refuses ur request, or doesn’t respond in a timely manner, the onus to fix the mess is on us.

The headline is misleading. The article is written for those supporting py37 or py38. These are both no longer supported.

The section on uv i was interested in reading, but it’s just fluff followed by a link.

The section on Pydantic should compare against dataclasses and attrs. All of which are capable of data validation. dataclasses is built-in.

The section on ruff did not compare against flake8+black+isort.

The section on typing-extensions, i have questions. When not to use typing-extensions. I look at the typing features being used and then create a nudge pin like,

typing-extension; python_version<="3.11"

or

typing-extension>=4.12.2; python_version<="3.11"

The nudge pins are placed into a pins-typing.in file. And included by another .in file with a line -c pins-typing.in

Have been using pyenv, but not pyenv-virtualenv. And don’t use an IDE.

Although the article was written many years ago, would suggest separate sections for installing and using: pyenv and pyenv-virtualenv.

RStudio/reticulate needs environment variables. Vanilla pyenv does not.

Would be nice to have something to compare against (article sections): pyenv vs pyenv+pyenv-virtualenv vs pyenv+reticulate

Thank you. Took me awhile to internalize your very generous and detailed advice

target spelling correction: maintainerclean --> maintainer-clean

Here is the docs covering the topic

GNU Make standard targets

Actions taken

1. In Makefile, separate GNU Make standard targets from other target categories

2. Rename make coverage --> make check. This would require including tests/ in tarball

3. Consider creating targets distclean and maintainer-clean

4. In MANIFEST.in, remove git related files: .gitignore, .github/**/*

5. Removed config files: codecov.yml, .readthedocs.yml

I use stub files and mypy, but have concerns about behavior.

Thought the point is to move the static type checking stuff into a separate file. This makes the code much easier to read.

1. When a particular stub file becomes out of date, contents don’t reflect what’s going on in the code, there is no warning.

2. inner functions are ignored.

3. a functions contents are ignored.

Reluctant to use a library running node (gh actions aside) or Rust. My opinion is speed and correctness are insufficient arguments to introduce another tech stack. If something breaks, suddenly the onus is on me to understand why. That’s complicated if the additional tech stack is in a coding language i’m unfamiliar with.

This takes out: ruff, uv, and pyright. And whatever else comes out.

Have seven published python packages.

Trying to be open minded. Please layout other arguments why should be open to utilizing other tech stacks.