Agreed. On the beloved GNU/Linux distros, when you "$ python" and it's not installed, Package Kit will recommend you to install it through the native package manager (like apt or dnf). This is literally the same thing. Windows Store is the package manager for Windows.

The difference is implementation. GNU/Linux systems do not hijack the 'python' executable. If such an executable is on the path, they will use it. If Python is not installed a program can check the path and see that Python is not installed.

It is only when the user tries to run python on the terminal that the system (I presume the shell) detects that the program does not exist, and it then executes another program to inform the user.

If you put python as the #! interperator for a script, then bash will complain that interperator cannot be found.

If it is used as a command as part of a script, then bash does not call the normal command-not-found program (which advises you to install it), but just prints to stderr that the command was not found.

Windows doesn't "hijack" the python executable either. This stub should be a low priority in your PATH and the official Python installers should take higher priority when they install. It's basic PATH management, with much the same environment variable management issues on Linux as it is on Windows.

It's unfortunate that so many machines that this poster is working with are getting malformed PATH variables with the priorities out of order, but it should be a simple fix to the PATH to correct.

It should also probably be noted that the Microsoft/Windows Store installed version of Python is the official Python.org release. (It's CIed, and CDed directly from Python.org just as with any other release binary.)

Even with correct PATH management, Windows still hijacks the command when python is not installed; that it the mechanism it uses to advise you to install it. Linux distributions use a different mechanism that maintain the expected behaviour of there not being any program/comnand called "python" when python is not installed.

Windows solution in this case is a lazy hack that makes the system more brittle.

As an aside, Linux distributions tend not to have this sort of PATH management issue because (for better or worse) they tend not to modify PATH when installing software.

Good luck running dnf without python!

  $ head -1 /usr/bin/dnf
  #!/usr/libexec/platform-python

RHEL 8 uses a separate internal copy of Python for dnf, so yes, you can run dnf without the package which provides the python command.

It's "fake" in the sense that that program cannot do anything that one would expect the program named python to be able to do. However well intended, it's a terrible idea.

This actually reminds me a lot of DNS servers that, when presented by an unknown name, will redirect the user to an ad page, or perhaps some page explaining how to otherwise look for the name. It doesn't help--it makes a mess. Just say "not found".

You don't think the "yet somehow figured out a way" blame maybe lies with Microsoft for breaking it instead of the user? Nice idea, problematic execution it seems.

Maybe Microsoft was trying to "help out the Python community". But what they did was just awful. Python is, by far, the most popular system glue language in the world. People have spent decades writing it and running it on windows. It has years of culture built up around version detection and deployment strategies, so that developers understand how to get "python" and exactly what they are getting when they do.

And now all of a sudden you run a "python" script and you get something that is not a python interpreter.

That's just insane. I don't doubt Microsoft's motives, but good grief is this dumb.

Install Python --> Run script?

Python adds itself to PATH on installation.

What did you have trouble with, and when was that? Python 2 used to not add itself to PATH iirc, but that was years ago.

Even for dependencies, I haven't had any trouble in many years, and I've supported people of all skill levels on half a dozen OSes.

Even the most complicated ML stuff that pip can't do alone, conda takes care of in seconds.

Python has made computing easier than any other single tech in my career, I think.

If you have some particular frustration with Python on Windows maybe I can give you some tips?

>it takes a lot of IT knowledge to get a python script to work properly on Windows

I know this wasn't the point of your post but as an aside - I am not a programmer but am very familiar with computers and I have so much difficulty running Python scripts that I just don't try any more and if that is the only solution to a problem I am having I just write it off as impossible. it's extraordinary to me how user unfriendly it is.

These days it's easier for me to pull a python docker image, then to figure out how to install it on my system.

Only for python do I develop inside docker.

The situation is unfortunate, but the grievance is legitimate. I regularly have to provide tech support to users when shell scripts fail with a terse "Permission denied" trying to invoke Python because the Windows Store launcher is higher on %PATH% than the Python that they just installed.