[issue41327] Windows Store "stub" Python executables give confusing behaviour

[Paul Moore]

New submission from Paul Moore <p.f.moore at gmail.com>:

First of all, I do know that this is an issue with the Windows Store distribution, rather than the python.org one. But (a) I don't know where to report a bug against the Store implementation except here, and (b) it's arguably a case of the Windows implementation "stealing" the Python command, so worth flagging against core Python.

The problem is that Windows 10 installs `python` and `python3` executables by default, which open the Windows Store offering to install Python. That's not a bad thing - it's nice to have Python available with the OS! Although (see below) hijacking the `python` and `python3` commands for this purpose has some problems.

But those stubs silently do nothing when run with command line arguments, and because the python.org distribution doesn't put Python on PATH by default, users end up with the stubs available even if they install python.org Python.

We're getting a lot of bug reports from users as a result of this, when they follow standard instructions like "execute `python -m pip`". With the stub on the path, this silently does nothing, even though the user has installed Python. This is a very bad user experience, and not one that projects like pip can do anything to alleviate, other than having extremely convoluted "how to run pip" commands:

"""
To run pip, type `python -m pip` if you're on Unix, and `py -m pip` on Windows. Unless you're using the Windows Store version when you should do `python -m pip` on Windows too. Or on Unix when you might need to do `python3 -m pip`. Or...
"""

I don't have a good answer to this issue. Maybe the Windows Store stubs could detect core Python and do something better if it's installed? Maybe the stubs should print an explanatory message if run with command line arguments? Maybe Store Python should be available on Windows via some less error-prone mechanism?

I'm pretty sure if a Linux distribution shipped a `python` command that didn't run Python the way users expected, there would be complaints. After all, we have PEP 394 that explicitly states how we expect Unix systems to work. Maybe we need something similar for Windows?

----------
assignee: steve.dower
components: Windows
messages: 373845
nosy: paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: Windows Store "stub" Python executables give confusing behaviour
versions: Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41327>
_______________________________________