While the author enumerates the things they think you should do, I think it was very light on the _why_ you would want this setup. I think the argument of "you are doing it the old way" have been really ineffective at convincing people to do anything different, particularly around python tooling.
"Bonus: Legacy Outdated Python Usage Warning Signs" was a helpful list of things to look at, but I disagree with many as best practices. I like when code from the year 2000 still works, and you do that by using standard packages.
The chase for the latest / greatest means bitrot and is the sign of a junior developer. You save a bit of time in the short term, but a new latest / greatest comes out a few years later.
The conclusion is a bit weird too. That kind of rant is what leads to no-hire decisions. Be careful what you put online.
Yeah I gotta agree here, I'm not sure I've seen someone so opinionated with python. I tend to try to use things built into python or official recs until I hit an actual problem that needs to be solved.
This is why I'm not posting this article to my team's slack. There's some good stuff in the article, but my team also has some well-meaning over-optimizers that will see this and start throwing in orjson even though json (de)serialization is an insignificant impact to our execution time, or loguru even though our code base has stupidly simple logging requirements, and they'll do it because they'll see this article stating authoritatively that those are the correct choices without considering the value of simplicity, the longevity of standard libraries, or whether the problems those libraries are trying to solve actually apply to us. And they'll do that because the author of this article failed to address or even acknowledge ANY of those concerns.
The official docs recommend doing many of the things the author cautions against or calls bad. https://packaging.python.org/en/latest/guides/distributing-p...