Python programming is drowning in red tape

> It was bikeshedding at its worst

It's ironic that discussions about formatting are taking up so much mindshare in the python community. For years all you'd hear was that whitespace significance was a sign of the lowliness of python. Meanwhile, tons of people were ignoring the bikeshedding and getting things done. Now it's one of the most widely used languages in existence.

The kinds of people that are focused on issues like formatting never seem to be focused on the things that actually matter - being productive and being able to get things done. That's what has always mattered about python, and what has always made it excellent.

> Type-annotated, asyncio-enabled Python hardly resembles the easy-to-understand language I fell in love with back in 2006.

true.

i am all for types in general and for types annotations in python. but i have seen some heavily type-annotated python code lately and i don't think that's where we want to be.

we are starting to look like a heavily templatized cpp code.

The author starts by criticising a bike-shedding mentality and then goes on to make bike-shedding arguments. They complain about the non-pep8 compliance, show what pep8 would look like and then argue that there's a better way..

As another commenter pointed out: This is all self-inflicted.

Personally, I don't care how things are formatted, I just want it to be consistent.

Honestly, this is one of the things I really appreciate about the development workflow at $dayjob. Our Python build process is fairly custom for what amounts to historical reasons, but when you create a new Python project, you get automated builds and tests on all the OSes you care about (through our central build and test farm), a way of declaring dependencies (that has nothing to do with pipenv/poetry/etc., but whatever), flake8 enabled by default easy toggles for mypy and black if you want them, a standard way of doing code reviews, a standard way of doing releases, etc. - simply because it's possible to assume shared infrastructure and shared defaults.

When you're writing open-source code, you don't have any shared infrastructure or defaults to assume, so you have to find some infrastructure (e.g. GitHub + Travis) and you have to basically include all the infrastructure configuration in your project, possibly through adding a bunch of dev-dependencies that set things up the way you want. It'd be interesting to think about how to abstract this further so you don't have to think about that many things.

Some possible inspirations:

- https://travis.debian.net/ - if you have a Debian package on GitHub, and you want automated tests, you just grab the .travis.yml file from here and a script written by someone else will set up builds and tests in Docker containers. It does rely on Debian having a standardized way of specifying build rules, dependencies, and tests and a standardized layout of packages, though. But most Python packages have a pretty standard layout, too, and you can imagine having things like isort/flake8/nose/etc. be installed only in CI and not explicitly listed in your code.

- Rust, I think, makes this a little easier because there's a high-quality packaging system, test runner, formatter, and doc generator all in the standard Rust tools. While Rust-the-language has a standard library that's much emptier than, say, Python's, rustc comes with way more developer tools than Python does. That means that you don't need to install custom tools to handle most of this because it's assumed that people are using the standard ones. (This does, of course, rely on the tools actually being high-quality, and as a young language, Rust has an unfair advantage in watching Python and so many other languages try to figure out what works well and what doesn't. You'd have an easier time in Python if you stuck to distutils and easy_install, but on the other hand, you'd have to use distutils and easy_install.)

All the "wait no" alternative tool suggestions are silly. There's a best tool.

For packaging a Python project, that tool is Poetry. Pipenv, virtualenv, setup.py, venv, setup.cfg, are all outmoded.