I’m a fan of pylint and recommend it to everyone. Is it much, much picker than other popular linters? Yes. But that’s a good thing, and typing “pylint” and an error/warning code into a search engine will bring up good documentation explaining what it was flagging and why, so for people newer to Python it’s a good educational tool as well. Here’s an example documentation page for one of the things flagged in the article.
And once you’ve worked with it for a while you start unconsciously writing “pylint style” – which is to say, better code than you used to – and it mostly fades into the background.
I’m a little confused why the author bemoans the pains of running pylint, but then dismisses pyflakes & flake8 as unnecessary, when they exist largely in response to those pains. Ruff may be the future, but if you’re not ready to make that jump, I’d be sticking with flake8.
Also given that pyenv wasn’t included in the sort of “prerequisite” basic tooling cited, I’d have included it. Some sort of dependency management would be a good fit, too… but that discussion could (and has) merited multiple articles of its own.
Huh, didn’t recognize the site, but I’d previously read that one wrt pyenv and seem to recall having some disagreements w/ some of the points in that one…might skim over it again though.
Imho, pyenv falls into the “fundamental building blocks that do one thing well” category of tools that belong in a dev’s python toolbox, at least at the moment. There may be some longer term solution that eliminates the need, but for now I wouldn’t leave it off the list.
FWIW I wholeheartedly recommend rtx as a replacement for pyenv, which you can use for the same purpose but for pretty much any runtime, not just Python, and it doesn’t rely on shims by default, but rather on updating PATH (unlike asdf).
I personally don’t particularly like the “integrate with everything” direction they’ve been going – I don’t want my version manager to be hooking into my shell, doing direnv stuff, spawning virtual environments, interacting w my package manager, etc… automatically, though I do understand the convenience for people who do.
Also, last I looked at asdf (and it’s been a while, and haven’t looked at all at what rtx has changed) it made it harder than pyenv if you needed to do anything custom in the cpython build… I’ve heard that’s improved, but haven’t checked again recently.
I agree regarding the extra stuff like creating/activating venvs, I only use it for managing runtimes and updating the PATH (which I guess does fall under “hooking into my shell,” though).
Good tips. This probably isn’t as relevant to the author’s target audience, but it used to be that to use
pdbyou had to doimport pdb; pdb.set_trace()But as of 2017 you no longer have to explicitly import pdb, you can just call the built-in
breakpoint. So just dobreakpoint()instead. Mentioning because a surprising number of experienced Python users don’t seem to know about even pdb
python -m pdb script.pyrunsscriptuntil it throws an exception, then drops into pdb.Yes, I link to it in the article, but there is a dedicated article on how to use pdb that mentions breakpoint(): https://www.bitecode.dev/p/intro-to-pdb-the-python-debugger
I will likely write a similar article for pylint, mypy, etc. But they are not there yet.
I’m a fan of
pylintand recommend it to everyone. Is it much, much picker than other popular linters? Yes. But that’s a good thing, and typing “pylint” and an error/warning code into a search engine will bring up good documentation explaining what it was flagging and why, so for people newer to Python it’s a good educational tool as well. Here’s an example documentation page for one of the things flagged in the article.And once you’ve worked with it for a while you start unconsciously writing “pylint style” – which is to say, better code than you used to – and it mostly fades into the background.
Yes, pylint is the best linter precisely because it’s so agressive. Still, I never use the default settings, its just too much for me.
doitseems pretty useful. Most of my workflows are powershell scripts, maybe I should be looking into using a workflow platform.Seems like mostly good advice.
I’m a little confused why the author bemoans the pains of running pylint, but then dismisses pyflakes & flake8 as unnecessary, when they exist largely in response to those pains. Ruff may be the future, but if you’re not ready to make that jump, I’d be sticking with flake8.
Also given that pyenv wasn’t included in the sort of “prerequisite” basic tooling cited, I’d have included it. Some sort of dependency management would be a good fit, too… but that discussion could (and has) merited multiple articles of its own.
The blog has a bit on deps management: “Reliving packaging pain” (https://www.bitecode.dev/p/relieving-your-python-packaging-pain)
It also has a bit on why it will not recommend pyenv: “Why not tell people to “simply” use pyenv, poetry or anaconda” (https://www.bitecode.dev/p/why-not-tell-people-to-simply-use)
Huh, didn’t recognize the site, but I’d previously read that one wrt pyenv and seem to recall having some disagreements w/ some of the points in that one…might skim over it again though.
Imho, pyenv falls into the “fundamental building blocks that do one thing well” category of tools that belong in a dev’s python toolbox, at least at the moment. There may be some longer term solution that eliminates the need, but for now I wouldn’t leave it off the list.
FWIW I wholeheartedly recommend rtx as a replacement for pyenv, which you can use for the same purpose but for pretty much any runtime, not just Python, and it doesn’t rely on shims by default, but rather on updating PATH (unlike asdf).
I personally don’t particularly like the “integrate with everything” direction they’ve been going – I don’t want my version manager to be hooking into my shell, doing direnv stuff, spawning virtual environments, interacting w my package manager, etc… automatically, though I do understand the convenience for people who do.
Also, last I looked at asdf (and it’s been a while, and haven’t looked at all at what rtx has changed) it made it harder than pyenv if you needed to do anything custom in the cpython build… I’ve heard that’s improved, but haven’t checked again recently.
I agree regarding the extra stuff like creating/activating venvs, I only use it for managing runtimes and updating the PATH (which I guess does fall under “hooking into my shell,” though).