On 22 Dec 2023, at 12:39, Sibylle Koczian via Python-list <python-list@python.org> wrote:

Hello,

I always install Python on Windows in the same manner:

- Python is not on the path,
- it is installed for all users,
- the Python Launcher is installed for all users,
- the file types .py, .pyw etc. are associated with Python.

My shebang line is usually "#!/usr/bin/env python3".

This has always worked well. I could run Python scripts in a console
window entering just the script name, by double clicking in the explorer
or using WIN+r; the two last variants for GUI or for scripts with
something like "input('Leave with Enter')" at the end.

Now I've got a new computer with Windows 11 and I've installed Python
3.12.1. On my older machine it's Windows 10 and Python 3.11.5. Reading
the Python documentation it seems my shebang lines should work as before
- but they don't. The error message:

"Unable to create process using 'C:\usr\bin\env\python "C:\Eigen\Src\launcher_versuche.py" ': Das System kann die angegebene
Datei nicht finden."

Without the "env" in the shebang line and only without it everything
works as expected - but that's contrary to the documentation, isn't it?

This suggests a typo in the shebang line. Is there a space between env and python?

Barry

Thank you for information,
Sibylle
--
https://mail.python.org/mailman/listinfo/python-list

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 22/12/2023 13.36, Sibylle Koczian wrote:

Hello,

I always install Python on Windows in the same manner:

- Python is not on the path,
- it is installed for all users,
- the Python Launcher is installed for all users,
- the file types .py, .pyw etc. are associated with Python.

My shebang line is usually "#!/usr/bin/env python3".

Disable BOM in your editor and re-save all files.

--
//Aho

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Am 22.12.2023 um 14:13 schrieb Barry:

On 22 Dec 2023, at 12:39, Sibylle Koczian via Python-list <python-list@python.org> wrote:

Hello,

I always install Python on Windows in the same manner:

- Python is not on the path,
- it is installed for all users,
- the Python Launcher is installed for all users,
- the file types .py, .pyw etc. are associated with Python.

My shebang line is usually "#!/usr/bin/env python3".

This has always worked well. I could run Python scripts in a console
window entering just the script name, by double clicking in the explorer
or using WIN+r; the two last variants for GUI or for scripts with
something like "input('Leave with Enter')" at the end.

Now I've got a new computer with Windows 11 and I've installed Python
3.12.1. On my older machine it's Windows 10 and Python 3.11.5. Reading
the Python documentation it seems my shebang lines should work as before
- but they don't. The error message:

"Unable to create process using 'C:\usr\bin\env\python
"C:\Eigen\Src\launcher_versuche.py" ': Das System kann die angegebene
Datei nicht finden."

Without the "env" in the shebang line and only without it everything
works as expected - but that's contrary to the documentation, isn't it?

This suggests a typo in the shebang line. Is there a space between env and python?

Barry

Tried several variants with the same script:

#!/usr/bin/env python3
# That's how I wrote it for Windows 10 / Python 3.11. It works there.

#!/usr/bin/env python
#!/usr/bin/env/python

The error messages vary a little. This is a German Windows installation,
the two variants with the space produce the same German error message,
the third produces the message I've put into my first description.

The working variant on Windows 11 / Python 3.12 is "#!/usr/bin python".

Thank you,
Sibylle

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

What is the "command line" on your Windows 11?

On Windows 10 it usually is "cmd.exe" (Windows Command Prompt).
On Windows 11 it usually is the "Terminal" which is different from
cmd.exe.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 22 Dec 2023, at 14:58, Christian Buhtz via Python-list <python-list@python.org> wrote:

On Windows 11 it usually is the "Terminal" which is different from cmd.exe.

In terminal app you can run cmd.exe or powershell, so it is basically the same.

Barry

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 22 Dec 2023, at 14:29, Sibylle Koczian <nulla.epistola@web.de> wrote:

#!/usr/bin/env/python

That was what i thought you had and it will not work.

The BOM suggestion is worth trying.

Barry

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 12/22/2023 7:36 AM, Sibylle Koczian via Python-list wrote:

Hello,

I always install Python on Windows in the same manner:

- Python is not on the path,
- it is installed for all users,
- the Python Launcher is installed for all users,
- the file types .py, .pyw etc. are associated with Python.

My shebang line is usually "#!/usr/bin/env python3".

This has always worked well. I could run Python scripts in a console
window entering just the script name, by double clicking in the explorer
or using WIN+r; the two last variants for GUI or for scripts with
something like "input('Leave with Enter')" at the end.

Now I've got a new computer with Windows 11 and I've installed Python
3.12.1. On my older machine it's Windows 10 and Python 3.11.5. Reading
the Python documentation it seems my shebang lines should work as before
- but they don't. The error message:

"Unable to create process using 'C:\usr\bin\env\python "C:\Eigen\Src\launcher_versuche.py" ': Das System kann die angegebene
Datei nicht finden."

Without the "env" in the shebang line and only without it everything
works as expected - but that's contrary to the documentation, isn't it?

How is a path for a linux location going to work on a Windows machine?
On Windows, when you click on a script the OS tries to find the program
that has been registered to run that script. Python would not have been installed to "C:\usr\bin\env\python".

On my Windows 10 machine, Python scripts run without a shebang line.
Perhaps Windows 11 has added the ability to use one, but then you would
need to use the actual location of your Python executable.

If you have several Python installations, it's better to run Python
scripts using the "py" launcher, because Windows may have the wrong idea
about which version to use. The "where" command on my computer shows
Python 3.9, but I'm actually using Python 12.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 12/22/2023 9:29 AM, Sibylle Koczian via Python-list wrote:

Am 22.12.2023 um 14:13 schrieb Barry:

On 22 Dec 2023, at 12:39, Sibylle Koczian via Python-list
<python-list@python.org> wrote:

Hello,

I always install Python on Windows in the same manner:

- Python is not on the path,
- it is installed for all users,
- the Python Launcher is installed for all users,
- the file types .py, .pyw etc. are associated with Python.

My shebang line is usually "#!/usr/bin/env python3".

This has always worked well. I could run Python scripts in a console
window entering just the script name, by double clicking in the explorer >>> or using WIN+r; the two last variants for GUI or for scripts with
something like "input('Leave with Enter')" at the end.

Now I've got a new computer with Windows 11 and I've installed Python
3.12.1. On my older machine it's Windows 10 and Python 3.11.5. Reading
the Python documentation it seems my shebang lines should work as before >>> - but they don't. The error message:

"Unable to create process using 'C:\usr\bin\env\python
"C:\Eigen\Src\launcher_versuche.py" ': Das System kann die angegebene
Datei nicht finden."

Without the "env" in the shebang line and only without it everything
works as expected - but that's contrary to the documentation, isn't it?

This suggests a typo in the shebang line. Is there a space between env
and python?

Barry

Tried several variants with the same script:

#!/usr/bin/env python3
# That's how I wrote it for Windows 10 / Python 3.11. It works there.

#!/usr/bin/env python
#!/usr/bin/env/python

The error messages vary a little. This is a German Windows installation,
the two variants with the space produce the same German error message,
the third produces the message I've put into my first description.

The working variant on Windows 11 / Python 3.12 is "#!/usr/bin python".

There is some important context that is missing here. Python on Windows
does not normally install to that location. That is not even a Windows
path, neither by directory name nor by path separators.

In addition, Powershell and cmd.exe do not use a shebang line, at least
through Windows 10. Instead, they use whatever executable has been
registered for a file extension. This may or may not be the version you
think. On my system, the OS will use Python 3.9, but actually the most
recent Python version on my system is Python 3.12. I can demonstrate the difference: here is a tiny Python file with a shebang line, called
showme.py:

#! %USERPROFILE%\AppData\Local\Programs\Python\Python312\python.exe
import sys
print(sys.executable)

Run this with the "py" launcher:
py showme.py
# prints C:\Users\tom\AppData\Local\Programs\Python\Python312\python.exe

Run it by invoking just the script's name:
showme.py
# prints C:\Program Files\Python39\python.exe

In neither case is the shebang line used.

This makes me think that maybe the Linux subsystem for Windows is being
used here. If so, possibly the syntax for a shebang line has been
tightened up, or there's a typo. Either way, I would not automatically
assume that Windows (at least through Windows 10) ever used the shebang
line for launching these scripts.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 23 Dec 2023, at 00:15, Thomas Passin via Python-list <python-list@python.org> wrote:

In neither case is the shebang line used.

As i understand it, not in front of my windows box to check.
The handler for .py file extension is set to be the py.exe
It is py.exe that understands shebang lines.

Barry

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 12/22/2023 7:19 PM, Barry wrote:

On 23 Dec 2023, at 00:15, Thomas Passin via Python-list <python-list@python.org> wrote:

In neither case is the shebang line used.

As i understand it, not in front of my windows box to check.
The handler for .py file extension is set to be the py.exe
It is py.exe that understands shebang lines.

Not on my system. It may depend on whether Python gets installed to
Program Files or to %USERPROFILE%/AppData/Local/Programs/Python. Python
3.9 is the last verson I installed to Program Files, and that's the
version that Windows thinks it should use to run Python files.

Run the little test program I posted. That will tell you which version
of Python the system wants to use.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Fri, 22 Dec 2023 17:27:58 -0700, Michael Torrie wrote:

Using the py launcher as your Windows association with .py and.pyw files
you can have multiple versions of python installed and everything works
as it should, according to your shebang, just like on Unix.

Does that work with virtualenv or conda? I'm slowly getting up to speed
with those.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 12/22/2023 7:27 PM, Michael Torrie via Python-list wrote:

On 12/22/23 07:02, Thomas Passin via Python-list wrote:

On my Windows 10 machine, Python scripts run without a shebang line.
Perhaps Windows 11 has added the ability to use one, but then you would
need to use the actual location of your Python executable.

Yes if you associate .py or .pyw with python.exe (or pythonw.exe), then things work as you describe. However it's no longer recommended to do
that.

Instead---and I think this is the default now when you install
python---you should associate both .py and .pyw files with the py
launcher (py.exe) and it will examine the shebang line of the script and determine which version of python to run. As I said this should work regardless of the path listed in the shebang. Note that the shebang is meaningless to Windows itself, and Windows Explorer. It is only
meaningful to the py launcher. So it's customary to just use a
unix-style shebang in your python scripts. So either #!/usr/bin/python3
or #!/usr/bin/env python3 as you would in unix.

Using the py launcher as your Windows association with .py and.pyw files
you can have multiple versions of python installed and everything works
as it should, according to your shebang, just like on Unix.

I actually don't remember how to set up the association for Python
files. I just always type the "py" launcher anyway, as in

py -m pip instal ...

I think that the association with py.exe must only happen if you install
to Program Files. As I said in my previous post, Windows still sticks
with launching Python files with Python 3.9 even though I'm three
version beyond that. 3.9 is the only one I installed to Program Files.

In my experience one should always make sure to know what version of
Python is being used, at least if there is more than one version
installed on the computer. Even on Linux using a shebang line can be
tricky, because you are likely to get the system's version of Python,
and that often is not what you want. OTOH you don't want to go
symlinking python3 to some other version of python because then the OS
system may not work right. So either you have to specify the Python
version in the shebang, or just specify the right version on the command
line. In that case you might as well not have included the shebang line
at all.

I may be more sensitive to this issue because I run many different Linux distros in VMs to check a few programs I support to make sure they can
run on Linux as well as Windows. What Linux, you ask? Well, who knows
what our users will use? So I'm always getting Python version
mix-and-match problems. The system will still be at Python 3.10 but I
need Python 3.11. The system uses Python 3.11 but we shouldn't (or
cannot) install our dependencies so we need a parallel install. Etc, etc.

It's just better not to make assumptions about which version of Python
will be running. Just specify it yourself when you can, and then you can
be sure.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 2023-12-22 22:56:45 -0500, Thomas Passin via Python-list wrote:

In my experience one should always make sure to know what version of Python is being used, at least if there is more than one version installed on the computer. Even on Linux using a shebang line can be tricky, because you are likely to get the system's version of Python,

You are not "likely" to get the system's version of Python, you get the
version of Python you specify. If you specify "/usr/bin/python3", that's
the system's version of Python. If you specify something else, you get something else. If you specify "/usr/bin/env python3", you get whatever
the user has in their PATH first.

and that often is not what you want. OTOH you don't want to go
symlinking python3 to some other version of python because then the OS
system may not work right. So either you have to specify the Python
version in the shebang,

This. In my considered opinion installed scripts should work regardless
pf the user's PATH, so they must have the correct interpreter in the
shebang. That specifying the correct shebang pulls in the complete
virtual environment is IMHO a great feature of Python.

I've written a small script "install-python" which basically just copies
a file and adjusts the shebang line. <https://git.hjp.at:3000/hjp/install-python/src/branch/master/install-python> for the use in Makefiles etc.

or just specify the right version
on the command line. In that case you might as well not have included the shebang line at all.

Right. However, that's not how scripts are usually invoked on Unix.
Using /usr/bin/env in the command line is supposed to fix that but of
course it assumes that your interpreter is actually called python3.

hp

--
_ | Peter J. Holzer | Story must make more sense than reality.
|_|_) | |
| | | hjp@hjp.at | -- Charles Stross, "Creative writing
__/ | http://www.hjp.at/ | challenge!"

-----BEGIN PGP SIGNATURE-----

iQIzBAABCgAdFiEETtJbRjyPwVTYGJ5k8g5IURL+KF0FAmWGtvUACgkQ8g5IURL+ KF1Yow//XMka2PPnVMUPZa0fIHjaEH7a8AwVC5ddv/QICWr39gOycyZZcu++o2T9 KxSajtWC2axAVvlurjdt4WJMpsIl3ti8iRAVbhXJq/+98HBFARZ5tYZ7U0gsSt7R wL/RfmyvJzd1fLLo/4lqyE2m+tE/yN9HG3yO6gQMK+es8+x795IV3bImEUiJPXBs 7jHHhr7DRwMzSnvRuwhkn7EF34KUxfETmzx0y4FZ8ePQErht9a9hkgY4nPPgnp+S VxVt6oQRRIokqfGUqCIDZy0PaMI2zVn5xicwMtttYFu4qjCA5k1ftp8cJWO49d5W ojYl43+3GpHcp7hEIrfpOb4CgJuopc8BT3L/fmlsEH6v9K+gdjwvVFwMsBIzbYvE ++zx5PosjRAchf8MbIQmEL6yC1r2z6KYtmwOIfwzUfW21kJ15CTh16xNgaKi9b6d Tczqfj3zK5sPcr9VMpqYbq+SfzNOnNiphpRoh0R4vuEdNpDx4HljOBgp8SsNDSQj XJ67dcyrkO3ZFhsWxV/9SIh79o7qYO4WvQmIVKD1pxZ6wlgCQGu98Ks8aakA9wTM mR9+K+NPLSClJFXvmH9K6OZG4zb67pyiYglPenEIQl6A1oPfOOS5nUDurfMBwgfX 3ZnYt7EAZKE7nHYjIUEa6JBb2fzzJfM9OshaBe1

On 23 Dec 2023, at 03:01, Thomas Passin via Python-list <python-list@python.org> wrote:

Not on my system. It may depend on whether Python gets installed to Program Files or to %USERPROFILE%/AppData/Local/Programs/Python. Python 3.9 is the last verson I installed to Program Files, and that's the version that Windows thinks it should use

to run Python files.

Run the little test program I posted. That will tell you which version of Python the system wants to use.

I always install for all users and this what I get on my Windows 10 and 11 systems.
As you can see the shebang lines do what is expected based on the config of py.exe.

Maybe it works differently if you install for a single user only,
I do not have such a setup to test with.

Windows 10 output.

K:\shebang>py -0
-V:3.13 Python 3.13 (64-bit)
-V:3.13-32 Python 3.13 (32-bit)
-V:3.12 * Python 3.12 (64-bit)
-V:3.12-32 Python 3.12 (32-bit)
-V:3.11 Python 3.11 (64-bit)
-V:3.11-32 Python 3.11 (32-bit)
-V:3.10 Python 3.10 (64-bit)
-V:3.10-32 Python 3.10 (32-bit)
-V:3.9 Python 3.9 (64-bit)
-V:3.9-32 Python 3.9 (32-bit)
-V:3.8 Python 3.8 (64-bit)
-V:3.8-32 Python 3.8 (32-bit)
-V:3.7 Python 3.7 (64-bit)
-V:3.7-32 Python 3.7 (32-bit)
-V:3.6 Python 3.6 (64-bit)
-V:3.6-32 Python 3.6 (32-bit)
-V:3.5 Python 3.5
-V:3.5-32 Python 3.5-32
-V:3.4 Python 3.4
-V:3.4-32 Python 3.4-32
-V:2.7 Python 2.7
-V:2.7-32 Python 2.7-32

K:\shebang>type shebang_py2.py
#!/usr/bin/python2
from __future__ import print_function
import sys
print('I am python %r' % (sys.version_info,))

K:\shebang>py shebang_py2.py
I am python sys.version_info(major=2, minor=7, micro=17, releaselevel='final', serial=0)

K:\shebang>shebang_py2.py
I am python sys.version_info(major=2, minor=7, micro=17, releaselevel='final', serial=0)

K:\shebang>type shebang_py3.py
#!/usr/bin/python3
from __future__ import print_function
import sys
print('I am python %r' % (sys.version_info,))

K:\shebang>py shebang_py3.py
I am python sys.version_info(major=3, minor=12, micro=1, releaselevel='final', serial=0)

K:\shebang>shebang_py3.py
I am python sys.version_info(major=3, minor=12, micro=1, releaselevel='final', serial=0)

K:\shebang>type shebang_env_py3.py
#!/usr/bin/env python3
from __future__ import print_function
import sys
print('I am python %r' % (sys.version_info,))

K:\shebang>py shebang_env_py3.py
I am python sys.version_info(major=3, minor=12, micro=1, releaselevel='final', serial=0)

K:\shebang>shebang_env_py3.py
I am python sys.version_info(major=3, minor=12, micro=1, releaselevel='final', serial=0)

K:\shebang>type shebang_env_py3_10.py
#!/usr/bin/env python3.10
from __future__ import print_function
import sys
print('I am python %r' % (sys.version_info,))

K:\shebang>py shebang_env_py3_10.py
I am python sys.version_info(major=3, minor=10, micro=11, releaselevel='final', serial=0)

K:\shebang>shebang_env_py3_10.py
I am python sys.version_info(major=3, minor=10, micro=11, releaselevel='final', serial=0)

K:\shebang>assoc .py
.py=Python.File

K:\shebang>ftype Python.File
Python.File="C:\WINDOWS\py.exe" "%L" %*


Windows 11 output


: 11:52:10.36 K:\shebang
: \\BARNSTONE\barry> py -0
-V:3.12 * Python 3.12 (64-bit)
-V:3.12-32 Python 3.12 (32-bit)
-V:3.11 Python 3.11 (64-bit)
-V:3.11-32 Python 3.11 (32-bit)
-V:3.10 Python 3.10 (64-bit)
-V:3.9 Python 3.9 (64-bit)
-V:3.9-32 Python 3.9 (32-bit)
-V:3.8 Python 3.8 (64-bit)
-V:3.8-32 Python 3.8 (32-bit)

: 11:52:10.40 K:\shebang
: \\BARNSTONE\barry> type shebang_py2.py
#!/usr/bin/python2
from __future__ import print_function
import sys
print('I am python %r' % (sys.version_info,))

: 11:52:10.41 K:\shebang
: \\BARNSTONE\barry> py shebang_py2.py
No suitable Python runtime found
Pass --list (-0) to see all detected environments on your machine
or set environment variable PYLAUNCHER_ALLOW_INSTALL to use winget
or open the Microsoft Store to the requested version.

: 11:52:10.47 K:\shebang
: \\BARNSTONE\barry> type shebang_py3.py
#!/usr/bin/python3
from __future__ import print_function
import sys
print('I am python %r' % (sys.version_info,))

: 11:52:10.49 K:\shebang
: \\BARNSTONE\barry> py shebang_py3.py
I am python sys.version_info(major=3, minor=12, micro=0, releaselevel='final', serial=0)

: 11:52:10.52 K:\shebang
: \\BARNSTONE\barry> shebang_py3.py
I am python sys.version_info(major=3, minor=12, micro=0, releaselevel='final', serial=0)

: 11:52:10.58 K:\shebang
: \\BARNSTONE\barry> type shebang_env_py3.py
#!/usr/bin/env python3
from __future__ import print_function
import sys
print('I am python %r' % (sys.version_info,))

: 11:52:10.60 K:\shebang
: \\BARNSTONE\barry> py shebang_env_py3.py
I am python sys.version_info(major=3, minor=12, micro=0, releaselevel='final', serial=0)

: 11:52:10.65 K:\shebang
: \\BARNSTONE\barry> shebang_env_py3.py
I am python sys.version_info(major=3, minor=12, micro=0, releaselevel='final', serial=0)

: 11:52:10.72 K:\shebang
: \\BARNSTONE\barry> type shebang_env_py3_10.py
#!/usr/bin/env python3.10
from __future__ import print_function
import sys
print('I am python %r' % (sys.version_info,))

: 11:52:10.72 K:\shebang
: \\BARNSTONE\barry> py shebang_env_py3_10.py
I am python sys.version_info(major=3, minor=10, micro=11, releaselevel='final', serial=0)

: 11:52:10.77 K:\shebang
: \\BARNSTONE\barry> shebang_env_py3_10.py
I am python sys.version_info(major=3, minor=10, micro=11, releaselevel='final', serial=0)

: 11:52:10.83 K:\shebang
: \\BARNSTONE\barry> assoc .py
.py=Python.File

: 11:52:10.83 K:\shebang
: \\BARNSTONE\barry> ftype Python.File
Python.File="C:\WINDOWS\py.exe" "%L" %*

Barry

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 24 Dec 2023, at 00:54, rbowman via Python-list <python-list@python.org> wrote:

Does that work with virtualenv or conda? I'm slowly getting up to speed
with those.

Conda is its own thing, not need for py.exe.

Once you have created the venv you do not need py.exe as you will have pythob.exe in the venv bin folder.

Barry

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Sun, 24 Dec 2023 22:55:34 +0000, Barry wrote:

On 24 Dec 2023, at 00:54, rbowman via Python-list
<python-list@python.org> wrote:

Does that work with virtualenv or conda? I'm slowly getting up to speed
with those.

Conda is its own thing, not need for py.exe.

Once you have created the venv you do not need py.exe as you will have pythob.exe in the venv bin folder.

Thanks. That's what I have been doing and have never used py.exe. For
context Esri distributes ArcPy as a scripting language using 3.9. By
default the base install can't be modified so if you want additional
libraries or a tool like Spyder it has to be in a virtual.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------------Xp5csH8w8FWViphjx9qRu5OF
Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64

T24gMjkvMTIvMjAyMyAxMjowOSBwbSwgRsOpbGl4IEFuIHZpYSBQeXRob24tbGlzdCB3cm90 ZToNCj4gT24gMjAyMy0xMi0yNSAxMjozNiwgTWlrZSBEZXdoaXJzdCB3cm90ZToNCj4+DQo+ PiAzLiBZb3UgY2Fubm90IHRydXN0IE1pY3Jvc29mdC4gWW91IGNhbiB0cnVzdCBQeXRob24g U29mdHdhcmUgDQo+PiBGb3VuZGF0aW9uLiBQeXRob24gZnJvbSBQU0Ygd29ya3MgdGhlIHNh bWUgaW4gYWxsIGVudmlyb25tZW50cyAtIG9yIA0KPj4gaWYgbm90IGl0IGlzIGEgYnVnLiBQ eXRob24gZnJvbSBNaWNyb3NvZnQgaXMgdHdlYWtlZCB0byBzYXRpc2Z5IHRoZWlyIA0KPj4g YWZvcmVtZW50aW9uZWQgc3RyYXRlZ3kgb2YgbG9ja2luZyBpbiB1c2VycyB0byBXaW5kb3dz Lg0KPj4NCj4NCj4gSSBzdHJvbmdseSBkaXNhZ3JlZSB3aXRoIHRoaXMuDQoNCk5vdCBzdXJl IHdoaWNoIHBhcnQgb2YgdGhlIGFib3ZlIHlvdSBzdHJvbmdseSBkaXNhZ3JlZSB3aXRoLiBJ IG1pZ2h0IA0Kc2VlbSBhIGJpdCBPVFQgd2l0aCAiWW91IGNhbm5vdCB0cnVzdCBNaWNyb3Nv ZnQiIGJ1dCBJIGRpZCBwdXQgaXQgaW4gYSANCnNwZWNpZmljIGNvbnRleHQuDQoNClBTRiBk b2VzIHRyeSB0byBtYWtlIFB5dGhvbiB3b3JrIGlkZW50aWNhbGx5IGluIGFsbCBvcGVyYXRp bmcgc3lzdGVtcyBpdCANCnN1cHBvcnRzLiBUaGUgT1Agd2FzIHVzaW5nIHB5LmV4ZSB3aGlj aCBJIGRpc2NvdmVyZWQgKGp1c3Qgbm93IC0gYW5kIGl0IA0KaXMgd2h5IEknbSB3cml0aW5n IHRoaXMpIGV4aXN0cyBvbiBteSBXaW5kb3dzIDEwIG1hY2hpbmUuIEkgaGF2ZSBuZXZlciAN Cmluc3RhbGxlZCBhbnkgUHl0aG9uIG90aGVyIHRoYW4gcGVyc29uYWxseSBkb3dubG9hZGVk IGZyb20gdGhlIA0KcHl0aG9uLm9yZyB3ZWJzaXRlIC0gdGhlcmVmb3JlIHB5LmV4ZSBtdXN0 IGhhdmUgY29tZSBmcm9tIFBTRiENCg0KSSBoYWQgYXNzdW1lZCB0aGUgT1AgaGFkIGluc3Rh bGxlZCBQeXRob24gZnJvbSB0aGUgTWljcm9zb2Z0IHNob3AgYW5kIA0KdGhhdCdzIHdoZXJl IHB5LmV4ZSBtdXN0IGhhdmUgY29tZSBmcm9tLg0KDQpJIGxlYXJuIHNvbWV0aGluZyBldmVy eSBkYXkuDQoNCj4gSSBkb24ndCBnZXQgYWxsIHRoZSBpcnJhdGlvbmFsIGhhdGUgZm9yIE1p Y3Jvc29mdCB0aGF0IGV4aXN0cyB3aXRoaW4gDQo+IHRoZSBMaW51eCBjb21tdW5pdHkuDQoN ClBlcmhhcHMgeW91IGFyZSB0b28geW91bmcgdG8gcmVtZW1iZXIgd2hlbiBTdGV2ZSBCYWxs bWVyIHdhcyBoZWFkIG9mIA0KTWljcm9zb2Z0Pw0KDQpIZSBzcGVjaWZpY2FsbHkgYW5kIGxv dWRseSBoYXRlZCBMaW51eCBhbmQgZGV2ZWxvcGVkIHRoZSBhbnRpLWxpbnV4IA0KY3VsdHVy ZS9zdHJhdGVneSB3aXRoaW4gTWljcm9zb2Z0LiBJZiBtZW1vcnkgc2VydmVzIGNvcnJlY3Rs eSBoZSBjYWxsZWQgDQppdCBhIHZpcnVzLiBUaGF0IHdhcyBpbiB0aGUgY29udGV4dCBvZiB0 cnlpbmcgdG8gZ2V0IHJpZCBvZiBMaW51eCBpbiANCkV1cm9wZSAoR2VybWFueSBJIHRoaW5r KSB3aGVyZSBpdCBoYWQgZ2FpbmVkIGEgc21hbGwgbXVuaWNpcGFsIGZvb3Rob2xkLiANCk1p Y3Jvc29mdCBldmVudHVhbGx5IHN1Y2NlZWRlZCBpbiByZXZlcnNpbmcgdGhhdCBwdWJsaWMg bWlzdGFrZS4NCg0KPiBJbiByZWNlbnQgeWVhcnMsIE1pY3Jvc29mdCBoYXMgbWFkZSBncmVh dCBjb250cmlidXRpb25zIHRvIHRoZSANCj4gZXZlcnlkYXkgbGlmZSBvZiBMaW51eCB1c2Vy cy4gVlMgQ29kZSBpcyBiYXNlZCBvbiBvcGVuIHNvdXJjZSBhbmQgDQo+IGF2YWlsYWJsZSBv biBMaW51eCwgLk5FVCBpcyBub3cgb24gTGludXgsIFdpbmRvd3MgaGFzIFdTTDIgYW5kIFZp c3VhbCANCj4gU3R1ZGlvIExpbnV4IGRldmVsb3BtZW50IHRvb2xzIHRvIGhlbHAgeW91IGRl dmVsb3Agc29mdHdhcmUgZm9yIExpbnV4LCANCj4gU1FMIFNlcnZlciAoZGVzcGl0ZSBzdGls bCBiZWluZyBjb21tZXJjaWFsIHNvZnR3YXJlIGV4Y2VwdCBmb3IgdGhlIA0KPiBFeHByZXNz IGFuZCBEZXZlbG9wZXIgdmVyc2lvbnMpIGlzIG9uIExpbnV4LCBldGMuDQoNCkkgb25seSB1 c2UgTGludXggb24gc2VydmVycyB3aXRob3V0IEdVSS4gSSBoYXZlIHVzZWQgV2luZG93cyBk ZXNrdG9wIA0Kc2luY2UgaXQgd2FzIHJlbGVhc2VkIGJlY2F1c2UgbW9zdCBvZiBteSBjbGll bnRzIHVzZWQgaXQuIEkgaGFkIG5vIA0KY2hvaWNlLiBJIGhhdmUgYmVlbiB3YXRjaGluZyB3 aGF0IHRoZXkgZG8gZm9yIGRlY2FkZXMuDQoNCkkgYWdyZWUgdGhleSBhcHBlYXIgdG8gaGF2 ZSBiZWNvbWUgbW9yZSBjaXZpbGlzZWQgaW4gcmVjZW50IHllYXJzLg0KDQpNDQoNCi0tIA0K U2lnbmVkIGVtYWlsIGlzIGFuIGFic29sdXRlIGRlZmVuY2UgYWdhaW5zdCBwaGlzaGluZy4g VGhpcyBlbWFpbCBoYXMNCmJlZW4gc2lnbmVkIHdpdGggbXkgcHJpdmF0ZSBrZXkuIElmIHlv dSBpbXBvcnQgbXkgcHVibGljIGtleSB5b3UgY2FuDQphdXRvbWF0aWNhbGx5IGRlY3J5cHQg bXkgc2lnbmF0dXJlIGFuZCBiZSBzdXJlIGl0IGNhbWUgZnJvbSBtZS4gWW91cg0KZW1haWwg c29mdHdhcmUgY2FuIGhhbmRsZSBzaWduaW5nLg0KDQo= --------------Xp5csH8w8FWViphjx9qRu5OF--

-----BEGIN PGP SIGNATURE-----

wsB5BAABCAAjFiEE/NCg7Xf1UydoVFgpGvW31BqCOLMFAmWPiMkFAwAAAAAACgkQGvW31BqCOLNp zwgAk1c9VgvdhXT6RifyRqPfFSWA6+oRe51kfRCaxE9nQ/uwrpFH1fPsZJ/eYTIZwH9r0m0UgTL6 BH6OesRGmlJ5L7QwbZ+Wl9qN9rN0DVMzXZBR91QLHMuPx7x97aPPShOUpCuD0lUPzvlTpU8ki9uE Qz7pW84TLXUOhpegEY/TWjeNYQHWrSfrRte4zHoxbKr5sluqm9Bwruhdcr5j3Hn89taz5GeTW1xk Qhu5+9YLW/+d5DWgkPALQqVXox6rEuIWFPzrq9agbO2LaTt+8b/ZdmSbnjf+VgpDIF2P3dbCTiuI rPSJ7CJqw1NDF6VL5fRlrqAGZNe/ilYcAhDwRRt4Bw==
=nIUJ
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Am 30.12.2023 um 04:04 schrieb Mike Dewhirst via Python-list:

I had assumed the OP had installed Python from the Microsoft shop and
that's where py.exe must have come from.

In fact I didn't say in my post that I always get Python from
python.org. When I started to use the language there was no Python from
any Microsoft shop (I'm not sure there was a Microsoft shop, it was in
the last millenium, Python 1.5 or 1.6). So I tend to forget that
possible download source.

But in all this thread I didn't see a single explanation for my current situation: one and the same shebang line works on Windows 10 / Python
3.11 and doesn't work on Windows 11 / Python 3.12. I suspect Windows,
because a change in the way Python 3.12 uses shebang lines should be
visible in the documentation.

Happy new year to all!
Sibylle

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 1 Jan 2024, at 11:14, Sibylle Koczian via Python-list <python-list@python.org> wrote:

But in all this thread I didn't see a single explanation for my current situation: one and the same shebang line works on Windows 10 / Python 3.11 and doesn't work on Windows 11 / Python 3.12. I suspect Windows, because a change in the way Python 3.12

uses shebang lines should be visible in the documentation.

See my earlier reply with info on ftype etc output.
What do you see on your windows 10 vs windows 11?

Barry

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 1/1/2024 6:02 AM, Sibylle Koczian via Python-list wrote:

Am 30.12.2023 um 04:04 schrieb Mike Dewhirst via Python-list:

I had assumed the OP had installed Python from the Microsoft shop and
that's where py.exe must have come from.

In fact I didn't say in my post that I always get Python from
python.org. When I started to use the language there was no Python from
any Microsoft shop (I'm not sure there was a Microsoft shop, it was in
the last millenium, Python 1.5 or 1.6). So I tend to forget that
possible download source.

But in all this thread I didn't see a single explanation for my current situation: one and the same shebang line works on Windows 10 / Python
3.11 and doesn't work on Windows 11 / Python 3.12. I suspect Windows,
because a change in the way Python 3.12 uses shebang lines should be
visible in the documentation.

Happy new year to all!
Sibylle

Happy New Year!

I speculated that the shebang line didn't work on Windows 10 either, but
you didn't realize it because the file associations were right to launch
".py" programs with the right version of Python. When the newer version
of Python got installed, the default Python program to use, was not
updated correctly, and the shebang line still has nothing to do with the
launch failure. This could happen if other the older install went into
Program Files, while the newer one went into %USERPROFILE%\AppData\Local\Programs\Python.

This was backed up with all of 5 minutes of experimenting on my own
computer, on which Windows launches ".py" programs with an old install
of Python 3.9.9, but the py launcher launches Python 3.12 by default.

Since I am avoiding Windows 11, I can't try anything on it, so my
thoughts above may not be relevant.

The Python docs for 3.12.1 cover shebang lines at

https://docs.python.org/3/using/windows.html

"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

For example, if the first line of your script starts with

#! /usr/bin/python
The default Python will be located and used. As many Python scripts
written to work on Unix will already have this line, you should find
these scripts can be used by the launcher without modification. If you
are writing a new script on Windows which you hope will be useful on
Unix, you should use one of the shebang lines starting with /usr."

But

"The /usr/bin/env form of shebang line has one further special property.
Before looking for installed Python interpreters, this form will search
the executable PATH for a Python executable matching the name provided
as the first argument. This corresponds to the behaviour of the Unix env program, which performs a PATH search. If an executable matching the
first argument after the env command cannot be found, but the argument
starts with python, it will be handled as described for the other
virtual commands. The environment variable PYLAUNCHER_NO_SEARCH_PATH may
be set (to any value) to skip this search of PATH.

Shebang lines that do not match any of these patterns are looked up in
the [commands] section of the launcher’s .INI file. This may be used to handle certain commands in a way that makes sense for your system. The
name of the command must be a single argument (no spaces in the shebang executable), and the value substituted is the full path to the
executable (additional arguments specified in the .INI will be quoted as
part of the filename)."

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 1/1/24 04:02, Sibylle Koczian via Python-list wrote:

Am 30.12.2023 um 04:04 schrieb Mike Dewhirst via Python-list:

I had assumed the OP had installed Python from the Microsoft shop and
that's where py.exe must have come from.

In fact I didn't say in my post that I always get Python from
python.org. When I started to use the language there was no Python from
any Microsoft shop (I'm not sure there was a Microsoft shop, it was in
the last millenium, Python 1.5 or 1.6). So I tend to forget that
possible download source.

But in all this thread I didn't see a single explanation for my current situation: one and the same shebang line works on Windows 10 / Python
3.11 and doesn't work on Windows 11 / Python 3.12. I suspect Windows,
because a change in the way Python 3.12 uses shebang lines should be
visible in the documentation.

The shebang support in the Python Launcher is documented here:

https://docs.python.org/3/using/windows.html#shebang-lines

That says the line you list originally:

My shebang line is usually "#!/usr/bin/env python3"

means look for python3 in PATH. Do you have one? If you don't have one,
you'll get one you don't want: the stupid Microsoft shim that, which if
run interactively, encourages you to install from the Microsoft store.
You should be able to disable this.

File suffix associations are a different thing - they give me no end of headaches on Windows. They start out bound to the shim, and should
rebind to the launcher when you install, but then things can steal it.
If you install Visual Studio Code with Python extensions, then it takes
over the running of .py files - if you click in the explorer, you'll get
it open in the editor, not run. I've argued about this, to no avail
(plays havoc with my testsuite, which in some places tries to execute
Python scripts as a cli command).

And then I've got this:

C:\Users\mats\SOMEWHERE>py -0
-V:3.13 Python 3.13 (64-bit)
-V:3.12 * Python 3.12 (64-bit)
-V:3.11 Python 3.11 (64-bit)
-V:3.10 Python 3.10 (64-bit)
-V:3.9 Python 3.9 (64-bit)
-V:3.8 Python 3.8 (64-bit)
-V:3.7 Python 3.7 (64-bit)
-V:3.6 Python 3.6 (64-bit)

# Okay, it knows about lots of Python versions, and shows a default of 3.12

C:\Users\mats\SOMEWHERE>py
Python 3.12.1 (tags/v3.12.1:2305ca5, Dec 7 2023, 22:03:25) [MSC v.1937
64 bit (AMD64)] on win32
Type "help", "copyright", "credits" or "license" for more information.

^Z

# Great, that works just as expected

C:\Users\mats\SOMEWHERE>py test.py
Python was not found; run without arguments to install from the
Microsoft Store, or disable this shortcut from Settings > Manage App
Execution Aliases.

# wait, what? if "py" worked, why doesn't "py test.py"?

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 1/1/2024 8:19 AM, Thomas Passin via Python-list wrote:

On 1/1/2024 6:02 AM, Sibylle Koczian via Python-list wrote:

Am 30.12.2023 um 04:04 schrieb Mike Dewhirst via Python-list:

I had assumed the OP had installed Python from the Microsoft shop and
that's where py.exe must have come from.

In fact I didn't say in my post that I always get Python from
python.org. When I started to use the language there was no Python
from any Microsoft shop (I'm not sure there was a Microsoft shop, it
was in the last millenium, Python 1.5 or 1.6). So I tend to forget
that possible download source.

But in all this thread I didn't see a single explanation for my
current situation: one and the same shebang line works on Windows 10 /
Python 3.11 and doesn't work on Windows 11 / Python 3.12. I suspect
Windows, because a change in the way Python 3.12 uses shebang lines
should be visible in the documentation.

Happy new year to all!
Sibylle

Happy New Year!

I speculated that the shebang line didn't work on Windows 10 either, but
you didn't realize it because the file associations were right to launch ".py" programs with the right version of Python.  When the newer version
of Python got installed, the default Python program to use, was not
updated correctly, and the shebang line still has nothing to do with the launch failure.  This could happen if other the older install went into Program Files, while the newer one went into %USERPROFILE%\AppData\Local\Programs\Python.

This was backed up with all of 5 minutes of experimenting on my own
computer, on which Windows launches ".py" programs with an old install
of Python 3.9.9, but the py launcher launches Python 3.12 by default.

Since I am avoiding Windows 11, I can't try anything on it, so my
thoughts above may not be relevant.

The Python docs for 3.12.1 cover shebang lines at

https://docs.python.org/3/using/windows.html

"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

For example, if the first line of your script starts with

#! /usr/bin/python
The default Python will be located and used. As many Python scripts
written to work on Unix will already have this line, you should find
these scripts can be used by the launcher without modification. If you
are writing a new script on Windows which you hope will be useful on
Unix, you should use one of the shebang lines starting with /usr."

But

"The /usr/bin/env form of shebang line has one further special property. Before looking for installed Python interpreters, this form will search
the executable PATH for a Python executable matching the name provided
as the first argument. This corresponds to the behaviour of the Unix env program, which performs a PATH search. If an executable matching the
first argument after the env command cannot be found, but the argument
starts with python, it will be handled as described for the other
virtual commands. The environment variable PYLAUNCHER_NO_SEARCH_PATH may
be set (to any value) to skip this search of PATH.

Shebang lines that do not match any of these patterns are looked up in
the [commands] section of the launcher’s .INI file. This may be used to handle certain commands in a way that makes sense for your system. The
name of the command must be a single argument (no spaces in the shebang executable), and the value substituted is the full path to the
executable (additional arguments specified in the .INI will be quoted as
part of the filename)."

Here's how to find out what program Windows thinks it should use to run
a ".py" file. In a console:

C:\Users\tom>assoc .py
.py=Python.File

C:\Users\tom>ftype Python.file
Python.file="C:\Windows\py.exe" "%L" %*

If your ".py" files are associated to the py.exe launcher, as mine are,
then the launcher may try to use your shebang line and you need to make
sure there aren't any spaces where there shouldn't be.

If your ".py" files are not associated with py.exe, the shebang line
probably won't be used for anything.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 1/1/24 07:11, Thomas Passin via Python-list wrote:

Here's how to find out what program Windows thinks it should use to run
a ".py" file.  In a console:

C:\Users\tom>assoc .py
.py=Python.File

C:\Users\tom>ftype Python.file
Python.file="C:\Windows\py.exe" "%L" %*

That's not enough. There is now (has been for a while) a layered system,
and this gives you just one layer, there may be other associations that
win out.

Per somebody who actually knows:

The only way to determine the association without reimplmenting the

shell's search is to simply ask the shell via AssocQueryString. Possibly PowerShell can provide this information. – Eryk Sun

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 1/1/2024 12:26 PM, Mats Wichmann via Python-list wrote:

On 1/1/24 07:11, Thomas Passin via Python-list wrote:

Here's how to find out what program Windows thinks it should use to
run a ".py" file.  In a console:

C:\Users\tom>assoc .py
.py=Python.File

C:\Users\tom>ftype Python.file
Python.file="C:\Windows\py.exe" "%L" %*

That's not enough. There is now (has been for a while) a layered system,
and this gives you just one layer, there may be other associations that
win out.

Per somebody who actually knows:

The only way to determine the association without reimplmenting the

shell's search is to simply ask the shell via AssocQueryString. Possibly PowerShell can provide this information. – Eryk Sun

"Possibly", eh? In fact, on my system those layers must be in effect,
since ftype claims that the "py" launcher will be used but in actual
fact the old Python 3.9.9 is used instead, as I wrote earlier. This is verified by this tiny Python script:

# Optional shebang line here
import sys
print(sys.executable)

Then run it with "py", a proposed shebang line, its plain name on the
command line, whatever. That will tell you for sure which Python
executable gets launched by which technique.

On Windows 10, a shebang line gets ignored in favor of Python 3.9.9 (if
invoked by the script name alone) or Python 3.12.1 (if invoked by the
"py" launcher).

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 1/1/24 12:53, Thomas Passin via Python-list wrote:

On Windows 10, a shebang line gets ignored in favor of Python 3.9.9 (if invoked by the script name alone) or Python 3.12.1 (if invoked by the
"py" launcher).

fwiw, you can also create an ini file to define to the launcher py which version should be the default, if no version is specified.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 1/2/2024 11:56 AM, Mats Wichmann via Python-list wrote:

On 1/1/24 12:53, Thomas Passin via Python-list wrote:

On Windows 10, a shebang line gets ignored in favor of Python 3.9.9
(if invoked by the script name alone) or Python 3.12.1 (if invoked by
the "py" launcher).

fwiw, you can also create an ini file to define to the launcher py which version should be the default, if no version is specified.

You might learn about this if you happen to read and remember the right
part of the Python docs. Otherwise you have no idea what py.exe is up
to nor how it does it. I would say that most people don't know there's
an ini file, let alone what it can do. Of course this situation isn't
unique to py.exe!

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 2 Jan 2024, at 17:24, Thomas Passin via Python-list <python-list@python.org> wrote:

You might learn about this if you happen to read and remember the right part of the Python docs. Otherwise you have no idea what py.exe is up to nor how it does it. I would say that most people don't know there's an ini file, let alone what it can do.

Of course this situation isn't unique to py.exe!

On discuss.python.org we will share the link to the python windows docs and often to this specific section: https://docs.python.org/3/using/windows.html#python-launcher-for-windows

To create a py.ini does require a user to understand what %localappdata% means. Some windows users, reasonable, do not use the CLI and know about that syntax for environment variables.

Barry

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Am 01.01.2024 um 12:50 schrieb Barry via Python-list:

On 1 Jan 2024, at 11:14, Sibylle Koczian via Python-list <python-list@python.org> wrote:

But in all this thread I didn't see a single explanation for my current situation: one and the same shebang line works on Windows 10 / Python 3.11 and doesn't work on Windows 11 / Python 3.12. I suspect Windows, because a change in the way Python 3.12

uses shebang lines should be visible in the documentation.

See my earlier reply with info on ftype etc output.
What do you see on your windows 10 vs windows 11?

Oh yes, I forgot to answer, here are my results:

py -0:
1. Windows 10, Python 3.11.5:
-V:3.11 * Python 3.11 (64-bit)
-V:3.6 Python 3.6 (64-bit) possibly part of Visual Studio or
else Calibre?
2. Windows 11, Python 3.12.1;
-V:3.12 * Python 3.12 (64-bit)

assoc .py
1. Windows 10, Python 3.11.5:
.py=Python.File
2. Windows 11, Python 3.12.1:
.py=Python.File

ftype Python.File
1. Windows 10, Python 3.11.5:
Python.File="C:\WINDOWS\py.exe" "%L" %*
2. Windows 11, Python 3.12.1:
Python.file="C:\Windows\py.exe" "%L" %*

Test Script test_shebang.py starts with one of these shebang lines:
a) #! python
b) #! /usr/bin/python
c) #! /usr/bin/env python
import sys
print(sys.executable)

Results:
1. Windows 10, Python 3.11.5:
test_shebang.py, Version a): C:\Program Files\Python311\python.exe
py test_shebang.py, Version a): C:\Program Files\Python311\python.exe

test_shebang.py, Version b): C:\Program Files\Python311\python.exe
py test_shebang.py, Version b): C:\Program Files\Python311\python.exe

test_shebang.py, Version c): C:\Program Files\Python311\python.exe
py test_shebang.py, Version c): C:\Program Files\Python311\python.exe

2. Windows 11, Python 3.12.1:
test_shebang.py, Version a): C:\Program Files\Python312\python.exe
py test_shebang.py, Version a): C:\Program Files\Python312\python.exe

test_shebang.py, Version b): C:\Program Files\Python312\python.exe
py test_shebang.py, Version b): C:\Program Files\Python312\python.exe

test_shebang.py, Version c):
Python konnte nicht gefunden werden. F³hren Sie die Verkn³pfung ohne Argumente aus, um sie ³ber den Microsoft Store zu installieren, oder deaktivieren Sie diese Verkn³pfung unter

py test_shebang.py, Version c):
Python konnte nicht gefunden werden. F³hren Sie die Verkn³pfung ohne Argumente aus, um sie ³ber den Microsoft Store zu installieren, oder deaktivieren Sie diese Verkn³pfung unter

It's a german Windows version, first sentence: "Python could not be
found". I don't really know how to translate the second sentence.

Oh, and the two Windows and Python versions are on two different computers.

Will remove the "/env" from my shebang lines, even if I don't understand
what's happening.

Thank you for helping,
Sibylle

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 7 Jan 2024, at 15:09, Sibylle Koczian via Python-list <python-list@python.org> wrote:

Oh, and the two Windows and Python versions are on two different computers.

Will remove the "/env" from my shebang lines, even if I don't understand what's happening.

Thanks for the details.

Only thing I can think of is that "python" may be defaulting to mean python 2. If you use "#!/usr/bin/env python3" it may work on both.

Did you creates a py.ini file to configure py.exe?

See if you have %userappdata%\py.ini on either windows 10 or windows 11.
If so what is its contents?

I've tried with and without a py.ini and cannot duplicate what you see.

Barry

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Am 09.01.2024 um 12:36 schrieb Barry Scott via Python-list:

On 7 Jan 2024, at 15:09, Sibylle Koczian via Python-list <python-list@python.org> wrote:

Oh, and the two Windows and Python versions are on two different computers. >>
Will remove the "/env" from my shebang lines, even if I don't understand what's happening.

Thanks for the details.

Only thing I can think of is that "python" may be defaulting to mean python 2.
If you use "#!/usr/bin/env python3" it may work on both.

No, it doesn't. That's the form I started with. When it didn't work I
thought "python3" might be too old, because Python 2 is dead for so long.

Did you creates a py.ini file to configure py.exe?

See if you have %userappdata%\py.ini on either windows 10 or windows 11.
If so what is its contents?

No to both.

I've tried with and without a py.ini and cannot duplicate what you see.

It really seems strange. Only thing I can think of - and I don't really
believe in that idea: as far as I know in Windows 11 the handling of
PATH has changed. My Python isn't on the path, perhaps that is it. A
shebang line without "/env" doesn't check the path, right?

Thank you for helping,
Sibylle

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 1/14/2024 7:48 AM, Sibylle Koczian via Python-list wrote:

Am 09.01.2024 um 12:36 schrieb Barry Scott via Python-list:

On 7 Jan 2024, at 15:09, Sibylle Koczian via Python-list
<python-list@python.org> wrote:

Oh, and the two Windows and Python versions are on two different
computers.

Will remove the "/env" from my shebang lines, even if I don't
understand what's happening.

Thanks for the details.

Only thing I can think of is that "python" may be defaulting to mean
python 2.
If you use "#!/usr/bin/env python3" it may work on both.

No, it doesn't. That's the form I started with. When it didn't work I
thought "python3" might be too old, because Python 2 is dead for so long.

Did you creates a py.ini file to configure py.exe?

See if you have %userappdata%\py.ini on either windows 10 or windows 11.
If so what is its contents?

No to both.

I've tried with and without a py.ini and cannot duplicate what you see.

It really seems strange. Only thing I can think of - and I don't really believe in that idea: as far as I know in Windows 11 the handling of
PATH has changed. My Python isn't on the path, perhaps that is it. A
shebang line without "/env" doesn't check the path, right?

From what I've read recently, if you have a Python program that starts
with a shebang line with any of four standard unix-like paths, then
Python (not Windows) will look for a version of Python in standard
locations - *NOT* in the shebang line locations:

"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
"

Also -
"The /usr/bin/env form of shebang line has one further special property.
Before looking for installed Python interpreters, this form will search
the executable PATH for a Python executable matching the name provided
as the first argument. This corresponds to the behaviour of the Unix env program, which performs a PATH search. If an executable matching the
first argument after the env command cannot be found, but the argument
starts with python, it will be handled as described for the other
virtual commands.
"

There are some other complications, too, depending on whether you
specify bare "python" or some specific version. The form with
"/usr/bin/env" is the closest to the unix behavior, in that it searches
the PATH. And you write that your intended version of Python is not on
the path.

IOW, these shebang lines don't work the way you seem to think that they do.

See https://docs.python.org/3/using/windows.html for a more complete
rundown.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 1/14/2024 8:54 AM, Thomas Passin via Python-list wrote:

On 1/14/2024 7:48 AM, Sibylle Koczian via Python-list wrote:

Am 09.01.2024 um 12:36 schrieb Barry Scott via Python-list:

On 7 Jan 2024, at 15:09, Sibylle Koczian via Python-list
<python-list@python.org> wrote:

Oh, and the two Windows and Python versions are on two different
computers.

Will remove the "/env" from my shebang lines, even if I don't
understand what's happening.

Thanks for the details.

Only thing I can think of is that "python" may be defaulting to mean
python 2.
If you use "#!/usr/bin/env python3" it may work on both.

No, it doesn't. That's the form I started with. When it didn't work I
thought "python3" might be too old, because Python 2 is dead for so long. >>>

Did you creates a py.ini file to configure py.exe?

See if you have %userappdata%\py.ini on either windows 10 or windows 11. >>> If so what is its contents?

No to both.

I've tried with and without a py.ini and cannot duplicate what you see.

It really seems strange. Only thing I can think of - and I don't
really believe in that idea: as far as I know in Windows 11 the
handling of PATH has changed. My Python isn't on the path, perhaps
that is it. A shebang line without "/env" doesn't check the path, right?

From what I've read recently, if you have a Python program that starts
with a shebang line with any of four standard unix-like paths, then
Python (not Windows) will look for a version of Python in standard
locations - *NOT* in the shebang line locations:

I meant to write "the Python launcher", that is, the "py" program.
Normal Python installs on Windows install the launcher and Windows will
run it on ".py" files if no other program has been specified on the
command line.

"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
"

Also -
"The /usr/bin/env form of shebang line has one further special property. Before looking for installed Python interpreters, this form will search
the executable PATH for a Python executable matching the name provided
as the first argument. This corresponds to the behaviour of the Unix env program, which performs a PATH search. If an executable matching the
first argument after the env command cannot be found, but the argument
starts with python, it will be handled as described for the other
virtual commands.
"

There are some other complications, too, depending on whether you
specify bare "python" or some specific version. The form with
"/usr/bin/env" is the closest to the unix behavior, in that it searches
the PATH.  And you write that your intended version of Python is not on
the path.

IOW, these shebang lines don't work the way you seem to think that they do.

See https://docs.python.org/3/using/windows.html for a more complete
rundown.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

QW0gMTUuMDEuMjAyNCB1bSAwMDo0NiBzY2hyaWViIE1pa2UgRGV3aGlyc3QgdmlhIFB5dGhv bi1saXN0Og0KPiBJbiBXaW5kb3dzIHRoZSBwcm92aWRlZCBtZXRob2RzIGZvciBydW5uaW5n IGNvbXBsZXggY29tbWFuZCBsaW5lcyBhcmUgZWl0aGVyIGEgYmF0Y2ggZmlsZSBvciBhIHNo b3J0Y3V0LlNvbWVvbmUgdmVyeSBraW5kbHkgcG9pbnRlZCBvdXQgdG8gbWUgaW4gdGhpcyB0 aHJlYWQgdGhhdCB0aGVyZSBpcyBhIFBFUCBmb3IgcHkuZXhlLsKgSSBkb24ndCB1c2UgcHku ZXhlIG9yaWdpbmFsbHkgYmVjYXVzZSBJIGRpZG4ndCB0cnVzdCBpdCBiZWxpZXZpbmcgaXQg d2FzIGEgbmV3LWZhbmdsZWQgTWljcm9zb2Z0IHRyaWNrLiBJIGRpZCByZWFkIHRoYXQgUEVQ IGJ1dCBpdCBoYXMgbm8gcmVsZXZhbmNlIGZvciBteSBtaXhlZCBXaW5kb3dzL0xpbnV4IGVu dmlyb25tZW50cy7CoE9uIHJlZmxlY3Rpb24gSSBub3cgYmVsaWV2ZSBJIHdvbid0IHVzZSBw eS5leGUgYmVjYXVzZSBpdCBpbnRyb2R1Y2VzIGFuIHVubmVjZXNzYXJ5IGxheWVyIG9mIGlu ZGlyZWN0aW9uLlRoZcKgIGJvdHRvbSBsaW5lIGlzIHRoYXQgeW91IHN0aWxsIG5lZWQgdG8g a25vdyB3aGljaCBQeXRob24gYSBwYXJ0aWN1bGFyIHNldCBvZiBjaXJjdW1zdGFuY2VzIGRl bWFuZHMgYW5kIGlmIHlvdSB1c2UgcHkuZXhlIHlvdSB0aGVuIG5lZWQgdG8gYWxzbyB1bmRl cnN0YW5kIGhvdyBpdCBjaG9vc2VzIGFuZCBob3cgaXQgaW50ZXJwcmV0cyBzaGViYW5nIGxp bmVzIHdyaXR0ZW4gZm9yIHlvdXIgTGludXggZW52aXJvbm1lbnQuwqBBbmQgaWYgdGhhdCBp c24ndCB5b3VyIHNpdHVhdGlvbiBJIGhhdmUganVtcGVkIHRvIHRoZSB3cm9uZyBjb25jbHVz aW9uLkkgaGF2ZSBmb3VuZCBubyBwcm9ibGVtIGluIFdpbmRvd3Mgd2hlbiBJIHVzZSBzaGVi YW5nIGxpbmVzIGluIHNjcmlwdHMgaW50ZW5kZWQgZm9yIGV4ZWN1dGlvbiBpbiBib3RoIExp bnV4IGFuZCBXaW5kb3dzLiBUaGV5IGFyZSBpZ25vcmVkIHVubGVzcyB5b3UgdXNlIHB5LmV4 ZS5NeSBhZHZpY2UgaXMgdG8gZ2l2ZSB1cCBweS5leGUgdW5sZXNzIHlvdXIgdXNlIGNhc2Ug bWFuZGF0ZXMgc2hlYmFuZyBsaW5lcyBpbiBXaW5kb3dzLk0tLShVbnNpZ25lZCBtYWlsIGZy b20gbXkgcGhvbmUpDQoNCkZpcnN0IGFuZCBmb3JlbW9zdCBJIHdhbnQgdG8gdW5kZXJzdGFu ZCB3aHkgSSdtIHNlZWluZyB0aGlzOg0KDQotIFB5dGhvbiBzY3JpcHRzIHdpdGggIi91c3Iv YmluL2VudiBweXRob24zIiBhcyBzaGViYW5nIGxpbmUgd29yayBhcyANCmV4cGVjdGVkIG9u IGEgY29tcHV0ZXIgd2l0aCBXaW5kb3dzIDEwIGFuZCBQeXRob24gMy4xMS41LiBUaGV5IGhh dmUgDQp3b3JrZWQgZm9yIHllYXJzIG9uIHRoaXMgbWFjaGluZSwgdXNpbmcgZWl0aGVyIHRo ZSBsYXRlc3QgUHl0aG9uIG9yIG9uZSANCnZlcnNpb24gYmVmb3JlIChkZXBlbmRpbmcgb24g YXZhaWxhYmlsaXR5IG9mIHNvbWUgcGFja2FnZXMpLiBUaGVyZSBpcyBhIA0KdmlydHVhbCBt YWNoaW5lIHdpdGggQXJjaExpbnV4IG9uIHRoZSBzYW1lIG1hY2hpbmUgYW5kIHNvbWUgb2Yg dGhlIA0Kc2NyaXB0cyBhcmUgY29waWVzIGZyb20gdGhhdC4NCg0KLSBJJ3ZlIGdvdCBhIHNl Y29uZCBjb21wdXRlciB3aXRoIFdpbmRvd3MgMTEgYW5kIEkgaW5zdGFsbGVkIFB5dGhvbiAN CjMuMTIuMSBvbiBpdC4gQWZ0ZXIgY29weWluZyBzb21lIHNjcmlwdHMgZnJvbSBteSBmaXJz dCBjb21wdXRlciBJIGZvdW5kIA0KdGhhdCBJIGNvdWxkbid0IHN0YXJ0IHRoZW06IG5vdCBi eSBlbnRlcmluZyB0aGUgc2NyaXB0IG5hbWUgaW4gYSANCmNvbnNvbGUsIG5vdCB1c2luZyBw eS5leGUsIG5vdCBkb3VibGUgY2xpY2tpbmcgaW4gdGhlIGV4cGxvcmVyLiBFbnRlcmluZyAN CjxmdWxsX3BhdGhfdG9fcHl0aG9uLmV4ZT5ccHl0aG9uIDxzY3JpcHRuYW1lPiBwcm9iYWJs eSB3b3JrZWQgLSBJIHRoaW5rIA0KSSB0cmllZCB0aGF0IHRvbywgYnV0IEknbSBub3QgcmVh bGx5IHN1cmUsIGJlY2F1c2UgdGhhdCdzIHJlYWxseSBub3QgDQpwcmFjdGljYWwuDQoNCklu IHRoZSBQeXRob24gZG9jdW1lbnRhdGlvbiBmb3IgdmVyc2lvbnMgMy4xMSBhbmQgMy4xMiBJ IGZvdW5kIG5vIA0KZGlmZmVyZW5jZXMgcmVnYXJkaW5nIHB5LmV4ZSBhbmQgc2hlYmFuZyBs aW5lcy4NCg0KVGhlbiBJIHJlbW92ZWQgdGhlICIvZW52IiBmcm9tIHRoZSBzaGViYW5nIGxp bmVzIGFuZCBjb3VsZCBzdGFydCB0aGUgDQpzY3JpcHRzIGZyb20gdGhlIHNlY29uZCBjb21w dXRlci4gVGhhdCBjZXJ0YWlubHkgaXMgYSBzb2x1dGlvbiwgYnV0IHdoeT8/Pw0KDQpTaWJ5 bGxlDQoNCg0KDQo=

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 1/15/24 09:44, Sibylle Koczian via Python-list wrote:

In the Python documentation for versions 3.11 and 3.12 I found no
differences regarding py.exe and shebang lines.

Then I removed the "/env" from the shebang lines and could start the
scripts from the second computer. That certainly is a solution, but why???

Sibylle

also, it looks like you can disable the PATH-searching behavior of the /usr/bin/env virtual path:

The environment variable PYLAUNCHER_NO_SEARCH_PATH may be set (to any

value) to skip this search of PATH.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 1/15/24 09:44, Sibylle Koczian via Python-list wrote:

First and foremost I want to understand why I'm seeing this:

- Python scripts with "/usr/bin/env python3" as shebang line work as
expected on a computer with Windows 10 and Python 3.11.5. They have
worked for years on this machine, using either the latest Python or one version before (depending on availability of some packages). There is a virtual machine with ArchLinux on the same machine and some of the
scripts are copies from that.

- I've got a second computer with Windows 11 and I installed Python
3.12.1 on it. After copying some scripts from my first computer I found
that I couldn't start them: not by entering the script name in a
console, not using py.exe, not double clicking in the explorer. Entering <full_path_to_python.exe>\python <scriptname> probably worked - I think
I tried that too, but I'm not really sure, because that's really not practical.

In the Python documentation for versions 3.11 and 3.12 I found no
differences regarding py.exe and shebang lines.

Then I removed the "/env" from the shebang lines and could start the
scripts from the second computer. That certainly is a solution, but why???

It's because of Windows itself. The default nowadays is that irritating
little stub that prompts you to go install Python from the WIndows
store. When you use the "env" form, it looks for python (or python3 in
your case) in the PATH *first* and you'll get a hit. Mine looks like:

C:\Users\mats\AppData\Local\Microsoft\WindwsApps\python.exe and python3.exe

you can check what it's doing for you by using the "where" command in a
windows shell.

On your older Windows 10 machine you either never had that stub - I
don't know when it was added, maybe someone from Microsoft listening
here knows - or it's been superseded by changes to the PATH, or
something. On my fairly new Win 11 box the base of that path is early
in the user portion of PATH, so that must be a default.

py.exe without the "/usr/bin/env" magic doesn't put PATH searching
first, according to that snip from the docs that's been posted here
several times., so you shouldn't fall down that particular rathole.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 1/15/2024 1:26 PM, Mats Wichmann via Python-list wrote:

On 1/15/24 09:44, Sibylle Koczian via Python-list wrote:

First and foremost I want to understand why I'm seeing this:

- Python scripts with "/usr/bin/env python3" as shebang line work as
expected on a computer with Windows 10 and Python 3.11.5. They have
worked for years on this machine, using either the latest Python or
one version before (depending on availability of some packages). There
is a virtual machine with ArchLinux on the same machine and some of
the scripts are copies from that.

- I've got a second computer with Windows 11 and I installed Python
3.12.1 on it. After copying some scripts from my first computer I
found that I couldn't start them: not by entering the script name in a
console, not using py.exe, not double clicking in the explorer.
Entering <full_path_to_python.exe>\python <scriptname> probably worked
- I think I tried that too, but I'm not really sure, because that's
really not practical.

In the Python documentation for versions 3.11 and 3.12 I found no
differences regarding py.exe and shebang lines.

Then I removed the "/env" from the shebang lines and could start the
scripts from the second computer. That certainly is a solution, but
why???

It's because of Windows itself.  The default nowadays is that irritating little stub that prompts you to go install Python from the WIndows
store.  When you use the "env" form, it looks for python (or python3 in
your case) in the PATH *first* and you'll get a hit.   Mine looks like:

C:\Users\mats\AppData\Local\Microsoft\WindwsApps\python.exe and python3.exe

you can check what it's doing for you by using the "where" command in a windows shell.

On your older Windows 10 machine you either never had that stub - I
don't know when it was added, maybe someone from Microsoft listening
here knows - or it's been superseded by changes to the PATH, or
something.  On my fairly new Win 11 box the base of that path is early
in the user portion of PATH, so that must be a default.

py.exe without the "/usr/bin/env" magic doesn't put PATH searching
first, according to that snip from the docs that's been posted here
several times., so you shouldn't fall down that particular rathole.

Python from the App Store is not the same as Python from python.org:

"The Microsoft Store package is a simple installation of Python that is suitable for running scripts and packages, and using IDLE or other
development environments. It requires Windows 10 and above, but can be
safely installed without corrupting other programs. It also provides
many convenient commands for launching Python and its tools."

- https://docs.python.org/3/using/windows.html

Also:

"The Windows Store distribution of Python is a sandboxed application ...
The internal components of Windows Store apps are protected from being
accessed from other applications, and so the PyXLL add-in cannot use the
Python DLLs and packages that are installed as part of the Windows Store
Python app."

From the PyXLL support site -

https://support.pyxll.com/hc/en-gb/articles/4417634326675-Python-installed-via-the-Windows-Store-cannot-be-used-with-PyXLL

The "py" launcher is installed by the installer from python.org.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 1/15/24 12:01, Thomas Passin via Python-list wrote:

On 1/15/2024 1:26 PM, Mats Wichmann via Python-list wrote:

On 1/15/24 09:44, Sibylle Koczian via Python-list wrote:

First and foremost I want to understand why I'm seeing this:

- Python scripts with "/usr/bin/env python3" as shebang line work as
expected on a computer with Windows 10 and Python 3.11.5. They have
worked for years on this machine, using either the latest Python or
one version before (depending on availability of some packages).
There is a virtual machine with ArchLinux on the same machine and
some of the scripts are copies from that.

- I've got a second computer with Windows 11 and I installed Python
3.12.1 on it. After copying some scripts from my first computer I
found that I couldn't start them: not by entering the script name in
a console, not using py.exe, not double clicking in the explorer.
Entering <full_path_to_python.exe>\python <scriptname> probably
worked - I think I tried that too, but I'm not really sure, because
that's really not practical.

In the Python documentation for versions 3.11 and 3.12 I found no
differences regarding py.exe and shebang lines.

Then I removed the "/env" from the shebang lines and could start the
scripts from the second computer. That certainly is a solution, but
why???

It's because of Windows itself.  The default nowadays is that
irritating little stub that prompts you to go install Python from the
WIndows store.  When you use the "env" form, it looks for python (or
python3 in your case) in the PATH *first* and you'll get a hit.   Mine
looks like:

C:\Users\mats\AppData\Local\Microsoft\WindwsApps\python.exe and
python3.exe

you can check what it's doing for you by using the "where" command in
a windows shell.

On your older Windows 10 machine you either never had that stub - I
don't know when it was added, maybe someone from Microsoft listening
here knows - or it's been superseded by changes to the PATH, or
something.  On my fairly new Win 11 box the base of that path is early
in the user portion of PATH, so that must be a default.

py.exe without the "/usr/bin/env" magic doesn't put PATH searching
first, according to that snip from the docs that's been posted here
several times., so you shouldn't fall down that particular rathole.

Python from the App Store is not the same as Python from python.org:

yes. this question is about the python.org distribution. but, Windows
natively has something called python.exe and python3.exe which is
interfering here, IF the python.org install isn't directed to put itself
into the path, AND if the "#!/usr/bin/env python3" form is used, causing
a search in PATH, which is the setup Sibylle has described, unless I've misunderstood details.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 16/01/24 11:55 am, Mats Wichmann wrote:

Windows
natively has something called python.exe and python3.exe which is
interfering here

I'm wondering whether py.exe should be taught to recognise these stubs
and ignore them. This sounds like something that could trip a lot of
people up.

--
Greg

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 1/15/2024 6:27 PM, Greg Ewing via Python-list wrote:

On 16/01/24 11:55 am, Mats Wichmann wrote:

Windows natively has something called python.exe and python3.exe which
is interfering here

I'm wondering whether py.exe should be taught to recognise these stubs
and ignore them. This sounds like something that could trip a lot of
people up.

There are registry entries that say where all the python.org install
locations are. I suppose, but don't know, that py.exe checks them. The registry entries are inComputer\HKEY_CURRENT_USER\SOFTWARE\Python\PythonCore

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 1/15/2024 7:24 PM, Thomas Passin wrote:

On 1/15/2024 6:27 PM, Greg Ewing via Python-list wrote:

On 16/01/24 11:55 am, Mats Wichmann wrote:

Windows natively has something called python.exe and python3.exe
which is interfering here

I'm wondering whether py.exe should be taught to recognise these stubs
and ignore them. This sounds like something that could trip a lot of
people up.

There are registry entries that say where all the python.org install locations are.  I suppose, but don't know, that py.exe checks them.  The registry entries are
in Computer\HKEY_CURRENT_USER\SOFTWARE\Python\PythonCore

For python.org installs that are installed for all users, the entries are in

Computer\HKEY_CURRENT_USER\SOFTWARE\Python\PythonCore

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Am 15.01.2024 um 23:55 schrieb Mats Wichmann via Python-list:

On 1/15/24 12:01, Thomas Passin via Python-list wrote:

On 1/15/2024 1:26 PM, Mats Wichmann via Python-list wrote:
Python from the App Store is not the same as Python from python.org:

yes. this question is about the python.org distribution. but, Windows natively has something called python.exe and python3.exe which is
interfering here, IF the python.org install isn't directed to put itself
into the path, AND if the "#!/usr/bin/env python3" form is used, causing
a search in PATH, which is the setup Sibylle has described, unless I've misunderstood details.

No, you didn't misunderstand any detail. It's exactly right. My Windows
10 box doesn't find anything for "where python", "where python3", while
the new Windows 11 machine finds the Microsoft stub. "Irritating" is a
very friendly attribute for that thing. Why must it be called
"python.exe" and not something else like the installation files from python.org?

I'll stop using "/env" - hopefully that won't create problems with the
scripts I use in the Linux VM. But in that case I'll know what's up.

Thank you very much!
Sibylle

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 16 Jan 2024, at 17:11, Sibylle Koczian via Python-list <python-list@python.org> wrote:

while the new Windows 11 machine finds the Microsoft stub

You can turn off the stub in windows settings. The magic windows jargon is “App Execution Aliases”. Once you find it in settings you can turn off
the python and python3 aliases.

Barry

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 1/16/24 10:00, Sibylle Koczian via Python-list wrote:

Am 15.01.2024 um 23:55 schrieb Mats Wichmann via Python-list:

On 1/15/24 12:01, Thomas Passin via Python-list wrote:

On 1/15/2024 1:26 PM, Mats Wichmann via Python-list wrote:
Python from the App Store is not the same as Python from python.org:

yes. this question is about the python.org distribution. but, Windows
natively has something called python.exe and python3.exe which is
interfering here, IF the python.org install isn't directed to put
itself into the path, AND if the "#!/usr/bin/env python3" form is
used, causing a search in PATH, which is the setup Sibylle has
described, unless I've misunderstood details.

No, you didn't misunderstand any detail. It's exactly right. My Windows
10 box doesn't find anything for "where python", "where python3",

Be interesting to know if your WIndows 10 has those files in place, and
it's just a missing path entry (a good thing, perhaps) that's causing it
not to be found there.

while the new Windows 11 machine finds the Microsoft stub. "Irritating" is a very friendly attribute for that thing. Why must it be called
"python.exe" and not something else like the installation files from python.org?

it will be replaced by the real "python.exe" from the Microsoft Store
install, if you go ahead and install that - I guess that's why that name
was chosen.

I'll stop using "/env" - hopefully that won't create problems with the scripts I use in the Linux VM. But in that case I'll know what's up.

Thank you very much!
Sibylle

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Am 17.01.2024 um 19:44 schrieb Mats Wichmann via Python-list:

Be interesting to know if your WIndows 10 has those files in place, and
it's just a missing path entry (a good thing, perhaps) that's causing it
not to be found there.

Yes. Python is not on the Path - by design.

while the new Windows 11 machine finds the Microsoft stub.

Not any more - see my reply to Barry.

Thanks to all who answered!
Sibylle

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Am 16.01.2024 um 23:44 schrieb Barry via Python-list:

On 16 Jan 2024, at 17:11, Sibylle Koczian via Python-list <python-list@python.org> wrote:

while the new Windows 11 machine finds the Microsoft stub

You can turn off the stub in windows settings. The magic windows jargon is “App Execution Aliases”. Once you find it in settings you can turn off the python and python3 aliases.

Thank you! That did it. These two settings were off in the older Windows
10 installation and on in the new Windows 11. Changed there and the
shebang lines with "/env" work as expected.

I didn't remember ever seeing these settings on my "old" computer, but
it seems I turned them off six years ago and completely forgot about
them. Or could that have been an older default?

"python" or "python3" in the shebang line doesn't seem to make a
difference, at least not on machines that never saw Python 2.

Very glad to know what was the matter here,
Sibylle

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)