Pro tip: outside Docker, don’t ever use the OS’s own Python if you can avoid it.
This includes Homebrew's Python installation, which will update by itself and break things.
(Technically, I use uv now, but to the same ends.)
Why not?
You almost always want to develop in a virtualenv so you can install the exact versions of things you need without conflicting with the ones the OS itself requires. If you're abstracting out the site-packages directory anyway, why not take one more step and abstract out Python, too? Things like pyenv and uv make that trivially easy.
For instance, this creates a new project using Python 3.13.
$ uv init -p python3.13 foo
$ cd foo
$ uv sync
$ .venv/bin/python --version
Python 3.13.0rc2
I did not have Python 3.13 installed before I ran those commands. Now I do. It's so trivially easy to have per-project versions that this is my default way of using Python.You can get 95% of the same functionality by installing pyenv and using it to install the various versions you might want. It's also an excellent tool. Python's own built-in venv module (https://docs.python.org/3/library/venv.html) makes it easy to create virtualenvs anytime you want to use them. I like using uv to combine that and more into one single tool, but that's just my preference. There are many tools that support this workflow and I highly recommend you find one you like and use it. (But not pipenv. Don't pick that one.)
Yes, make a venv for each work project.
If you're doing work on a large Python app for production software, then using system Python isn't going to cut it.