Ceci est une ancienne révision du document !
Python and Windows
Greetings fellow Beings. Working in Python means that, many times, the need arises to deal with cross-platform programming. Lately, when starting Python, the majority of us need to use ‘python3’, and, when using pip, we actually need to use ‘pip3’.
Some of us have aliased python3 to simply ‘python’ and pip3 to ‘pip’. This is especially easy with pyenv. Unfortunately, users of Microsoft Windows don’t have the ability to use pyenv. So for those Windows users, the problem is worsened because when Python is installed on their machine, it might get set up to use either ‘python’ or ‘python3’ or even ‘’python3.9’ to start Python. This extends to pip as well. To make matters worse, the shebang line (#!/usr/bin/env python3) that should start every Python file, will be wrong when Python is started with “python”.
So how do you create a batch file to make the startup process simple, and to work in every instance, and create a shebang that will work every time as well?
For the last few years, this problem has plagued the Sourceforge PAGE discussion forum. Many users don't bother looking at the previous posts to see if their issue has already been addressed, they seem to think that they are the only ones to have the issue. So the question gets answered multiple times with the same answer. Change the batch file command ‘python3’ to ‘python’ or vice versa.
Back in December, the Python-list digest had a thread about the shebang line no longer working correctly when running Python 3.12 under Windows 11. Knowing that this could trouble PAGE users, I started following the thread with interest. As expected, there were a number of responses that contained a “Well, it worked for me” kind of response but many of the responses were seriously trying to help the poster, without a definitive answer.
Eventually, there was a post that pointed to the Python for Windows documentation about using the shebang line. At first, that didn’t fix the issue for the poster, but for me, it gave me some valuable information. However I had to dig deeper into the documentation.
Since I run Linux for everything, and fire up a Windows machine only when I absolutely must, I never really looked into the “proper” way to install and start Python when it comes to a Windows machine.
The documentation located at https://docs.python.org/3/using/windows.html#python-launcher-for-windows was really an eye-opener for me. I never knew that there was a ‘launcher’ for Windows. I just assumed that Python was Python, and if the command to start Python was ‘python3’, that was what you should use. I couldn’t be more wrong.
It turns out that, as far back as Python 3.3, there has been a launcher for Windows, and the command to use the launcher is simply ‘py’ . You can still use python or python3, depending on how your python got installed, but the ‘py’ command will start python regardless. (There is a small caveat here. If Python 2.x was previously installed, the launcher might not have been installed correctly.)
If you have two instances of Python on the Windows machine, ‘py’ will start the latest version, but not the last installed version.
You can find all the versions that the Windows launcher will provide by doing a ‘py –list’ in the command prompt (shown below).
In the below screen print, version 3.12 will be the default whenever ‘py’ is called. If you want to use version 3.10 instead, simply call py with the version you want. For example…
py -3.10 -v
will return 3.10.10 (in my case).
There is a curious thing about Python and Windows. Many people have suggested using the ‘where python’ command in the command prompt. However, on my system with three versions of Python installed, what gets returned is…
C:\Users\gregg>where python C:\Users\gregg\AppData\Local\Programs\Python\Python312\python.exe C:\Users\gregg\AppData\Local\Microsoft\WindowsApps\python.exe
It shows only two versions, not three, and the second version is actually a zero-byte file. This is where the issue with the shebang comes in.
According to the Python https://docs.python.org/3/using/windows.html#shebang-lines :
“If the first line of a script file starts with #!, it is known as a “shebang” line. Linux and other Unix-like operating systems have native support for such lines, and they are commonly used on such systems to indicate how a script should be executed. This launcher allows the same facilities to be used with Python scripts on Windows, and the examples above demonstrate their use.
To allow shebang lines in Python scripts to be portable between Unix and Windows, this launcher supports a number of ‘virtual’ commands to specify which interpreter to use. The supported virtual commands are:
/usr/bin/env /usr/bin/python /usr/local/bin/python python “
Of course, the first three versions of the accepted virtual commands couldn’t possibly exist on Windows, but the launcher is supposed to handle them.
The problem can come from that zero-byte file I pointed out a few moments ago. In fact, when I started fighting the problem on my virtual Windows machine, I had the following zero byte files…
C:\Users\gregg\AppData\Local\Microsoft\WindowsApps\python.exe
C:\Users\gregg\AppData\Local\Microsoft\WindowsApps\python3.exe
For some reason, sometimes on a Windows 11 machine these zero-byte files can cause a message similar to…
“Unable to create process using 'C:\usr\bin\env\python”
I’ve never heard of this happening on a Windows 10 machine, but I suppose it COULD happen. Anyway, message after message came, suggestions were made, but there was nothing definitive that would fix the user’s problem until January 16. Finally someone suggested that Windows 11 was failing at the zero-byte Alias stub files. The suggestion was to turn off access to the Python stub files.
That fixed the user’s issue. But how do you get access to the alias settings to turn them off?
It isn’t easy to find. Thankfully the poster was able to give a way to find it.
Windows has a search box on the panel right next to the start menu.
In it, simply type (or even start to type) “Manage app execution aliases”.
This will bring up a Settings window that looks something like this. Find the two entries for “App Installer python.exe” and “App Installer python3.exe” and set them to off.
Close this window and reboot the machine.
Issue fixed!
That’s all for this month. I’m in the process of rebuilding my home office from a music room / electronics lab into a true office.
We’ll talk again next month.
Until next time, as always; stay safe, healthy, positive and creative!