Which suggests that, because python's on-ramp just got easier, it's long-term prospects just got better.
What I'm saying is that bundling a specific Python interpreter and separate package environment should be the default. I'm not sure what it'd take to get there for a vanilla python install. But more system-level interpreters is not it.
Currently, the way I know of to do that is pyenv . And I know PyCharm let's you pick a python version when you start a project (though I don't use pycharm so that may not be true anymore).
though ironically in a very unpythonic way there are a bunch of these python environment creators. (conda, virulenv , pipenv....)
pycharm lets you select you favorite, which is pretty nice.
I’m a seasoned programmer and I absolutely hate how you’re forced to use VirtualEnv with python. One of the absolutely biggest warts of its already poor package-management.
It literally makes everything which should be simple, something you suddenly need to handle. Atrocious.
I like it much better like .Net, Node or Rust (and many others) where the dependencies are entirely handled within a project, completely obsoleting the need for a hack solution like virtualenvs in the first place.
Even now for many languages I shy away from installing globally (I usually install to user if I'm lazy). I feel like in almost any language a "project" (venv) should be taught early on and be simple to use. Basically, the first time you need a third-party module. I feel like newcomers should be shown the REPL, how to save code to a file and run it, standard libraries, then a workspace and how libraries work. Python could be a great example because of the batteries-included model I don't need external libraries for many tasks.
I would like to reverse the question. If you can't install a virtualenv as step 1, the process of creating a virtualenv is simply too difficult and should be streamlined.