Not all Python users run containers, especially in the sciences. When you are teaching basics of data manipulation to people that have barely touched any programming language before, getting people to grok even virtual environments is not trivial.
Just do "docker run --rm -it debian:11" and you are ready to go.
Unfortunately as a developer it's more fiddly than that.
You need to mount your code into it. Then if you try commit changes to your code, you're a different user, so the commit is now messed up. Also you lost your dotfiles, so none of your aliases or other shortcuts work when you're in the container. You might need to connect to other services which now need to run in their own containers, and then they all need to talk to each other. Before you know it there's a whole litany of commands you need to run and configuration files you need to put together just to get started in the morning. Imo using containers on development machines is a big step backwards for developer productivity.
Virtual environment is just... cd in the directory. Run magic incantation to set that directory as the canonical one for your current shell. The end. IDEs will pick it up automatically.
The Python virtual environment and package management experience is still worse than pretty much any other programming language, but for me it's far and away better than using containers on a development machine.
I don't do that. I edit it on the host OS.
I just run the code inside the container.
I use containers regularly but adding them to a development workflow for a standalone python application I could just as easily run directly without having the additional complexity of navigating container boundaries always mystifies me.
docker run --rm -it -v $(pwd):/some/where debian:11
Most of the time I don't use plain Debian, but an image based on Debian which I have peppered with some convenience stuff.