In general, Paul’s scenarios align more with my intuition, but I also recognize that I’m, personally, much closer to his Scenario 2 than Scenario 1. (In full disclosure: I’ve never internalized using the py command, and, much worse, have python installs managed by conda, the official python installer, uv, and perhaps even a couple from pyenv-win. Suffice to say that I’m very excited by the idea of an official installation manager on Windows.)
As a user, what I’d love to see in the long term is a well thought out, unified set of commands that apply to all the major platforms for user-provided python scripts (i.e., Windows, OSX, and Linux at minimum). Someone above brought up rust and cargo, which I think is a reasonable analogy (although there are also clear differences). As I understand it, that design has three fundamental parts: rustc (the compiler), cargo (the environment manager), and rustup (the version manager/installer/upgrade tool). If we analogize this to Python, one can imagine a similar trio of python (the interpreter), py (the environment manager), and pymanage (the version installer/upgrade tool).
However, a key part of what makes the rust trio of commands work is that they work everywhere. As a Windows user, I don’t have to worry (too much) if a rust article/blog/document was written by a Windows user or a Unix one; the guidance around how to “do stuff” is the same.
That’s not the case in Python currently: Windows users are instructed to run Python via the py command, while the rest of the world uses python or python3 (and I don’t expect random blog posts to show two versions of every command snippet). Similarly, there’s complaints about the lack of an official Python installer on Linux, which, if I understand correctly, largely centers around the (entirely reasonable) desire to not break the distro’s system installed python or scripts.
While I don’t expect this release to solve this issue in one go, it would be a sorely missed opportunity if this proposal is not thought through with a long-term, cross-platform goal in mind. The easiest way to keep the clean separation is to have separate commands that are (mostly) used to perform the separate activities listed above (as others have noted, imbuing python on with special install powers is likely a non-starter on Linux).
Reading through Steve’s recent description of the technical constraints is helpful, and I get the “first use” challenge. If the Windows implementation of the python command needs a special ability to install an interpreter to handle the first use scenario, that’s fair enough - but this ability should ideally be disabled as soon as a functional interpreter is found or, as a poor second, strongly discouraged in the documentation.
I’m probably too naive, but I can imagine an implementation that has the python, py, and pymanage aliases all point to the same executable, and then have that executable determine its behavior based on the name it was called by and whether or not it was able to find an installed interpreter. However, it should be a goal to make sure that, outside of the first use, python behave the same as it does when called from within a venv or on non-Windows systems.