Mailing List Archive

On Fri, 29 Dec 2023 at 12:23, Félix An via Python-list
<python-list@python.org> wrote:
>
> On 2023-12-25 12:36, Mike Dewhirst wrote:
> >
> > 3. You cannot trust Microsoft. You can trust Python Software Foundation. Python from PSF works the same in all environments - or if not it is a bug. Python from Microsoft is tweaked to satisfy their aforementioned strategy of locking in users to Windows.
> >
>
> I strongly disagree with this. I don't get all the irrational hate for
> Microsoft that exists within the Linux community.

It's worth noting that Mike Dewhirst is NOT a spokesman for the Linux
community. One of the cool benefits freedom brings is that anyone's
allowed to be wrong :)

Not ALL of us hate Microsoft. I store the vast majority of my code on
GitHub, and it didn't make any difference when MS bought that company
(it was already a company, and their interests were always to make
money, and that was okay with me).

ChrisA
--
https://mail.python.org/mailman/listinfo/python-list

On 29/12/2023 12:09 pm, Félix An via Python-list wrote:
> On 2023-12-25 12:36, Mike Dewhirst wrote:
>>
>> 3. You cannot trust Microsoft. You can trust Python Software
>> Foundation. Python from PSF works the same in all environments - or
>> if not it is a bug. Python from Microsoft is tweaked to satisfy their
>> aforementioned strategy of locking in users to Windows.
>>
>
> I strongly disagree with this.

Not sure which part of the above you strongly disagree with. I might
seem a bit OTT with "You cannot trust Microsoft" but I did put it in a
specific context.

PSF does try to make Python work identically in all operating systems it
supports. The OP was using py.exe which I discovered (just now - and it
is why I'm writing this) exists on my Windows 10 machine. I have never
installed any Python other than personally downloaded from the
python.org website - therefore py.exe must have come from PSF!

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

I learn something every day.

> I don't get all the irrational hate for Microsoft that exists within
> the Linux community.

Perhaps you are too young to remember when Steve Ballmer was head of
Microsoft?

He specifically and loudly hated Linux and developed the anti-linux
culture/strategy within Microsoft. If memory serves correctly he called
it a virus. That was in the context of trying to get rid of Linux in
Europe (Germany I think) where it had gained a small municipal foothold.
Microsoft eventually succeeded in reversing that public mistake.

> In recent years, Microsoft has made great contributions to the
> everyday life of Linux users. VS Code is based on open source and
> available on Linux, .NET is now on Linux, Windows has WSL2 and Visual
> Studio Linux development tools to help you develop software for Linux,
> SQL Server (despite still being commercial software except for the
> Express and Developer versions) is on Linux, etc.

I only use Linux on servers without GUI. I have used Windows desktop
since it was released because most of my clients used it. I had no
choice. I have been watching what they do for decades.

I agree they appear to have become more civilised in recent years.

M

--
Signed email is an absolute defence against phishing. This email has
been signed with my private key. If you import my public key you can
automatically decrypt my signature and be sure it came from me. Your
email software can handle signing.

On Sat, 30 Dec 2023 at 14:06, Mike Dewhirst via Python-list
<python-list@python.org> wrote:
>
> On 29/12/2023 12:09 pm, Félix An via Python-list wrote:
> > On 2023-12-25 12:36, Mike Dewhirst wrote:
> >>
> >> 3. You cannot trust Microsoft. You can trust Python Software
> >> Foundation. Python from PSF works the same in all environments - or
> >> if not it is a bug. Python from Microsoft is tweaked to satisfy their
> >> aforementioned strategy of locking in users to Windows.
> >>
> >
> > I strongly disagree with this.
>
> Not sure which part of the above you strongly disagree with. I might
> seem a bit OTT with "You cannot trust Microsoft" but I did put it in a
> specific context.
>
> PSF does try to make Python work identically in all operating systems it
> supports. The OP was using py.exe which I discovered (just now - and it
> is why I'm writing this) exists on my Windows 10 machine. I have never
> installed any Python other than personally downloaded from the
> python.org website - therefore py.exe must have come from PSF!
>
> I had assumed the OP had installed Python from the Microsoft shop and
> that's where py.exe must have come from.
>
> I learn something every day.

If you'd done a little research, you might have found this:

https://peps.python.org/pep-0397/

Yes, it is from the official launcher. I don't see why you'd expect
Microsoft to go to the effort of building their own launcher when it
can be available for every Python user.

> > I don't get all the irrational hate for Microsoft that exists within
> > the Linux community.
>
> Perhaps you are too young to remember when Steve Ballmer was head of
> Microsoft?

How relevant is this?

I remember the days when OS/2 was the big target, and Microsoft was
the greatest anti-OS/2 voice out there. Does that affect the way I use
tools today? Is it even slightly relevant?

I remember when Intel had floating-point division issues in their
FPUs. Do I tell people "don't do floating-point math on Intel
processors"? Is it relevant?

ChrisA
--
https://mail.python.org/mailman/listinfo/python-list

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


--
https://mail.python.org/mailman/listinfo/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?

Barry


--
https://mail.python.org/mailman/listinfo/python-list

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


--
https://mail.python.org/mailman/listinfo/python-list

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.


--
https://mail.python.org/mailman/listinfo/python-list

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


--
https://mail.python.org/mailman/listinfo/python-list

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


--
https://mail.python.org/mailman/listinfo/python-list

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).

--
https://mail.python.org/mailman/listinfo/python-list

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.



--
https://mail.python.org/mailman/listinfo/python-list

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!

--
https://mail.python.org/mailman/listinfo/python-list

> 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


--
https://mail.python.org/mailman/listinfo/python-list

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


--
https://mail.python.org/mailman/listinfo/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.

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

--
https://mail.python.org/mailman/listinfo/python-list

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

--
https://mail.python.org/mailman/listinfo/python-list

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.
--
https://mail.python.org/mailman/listinfo/python-list

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.

--
https://mail.python.org/mailman/listinfo/python-list

In Windows the provided methods for running complex command lines are either a batch file or a shortcut.Someone very kindly pointed out to me in this thread that there is a PEP for py.exe. I don't use py.exe originally because I didn't trust it believing it was a new-fangled Microsoft trick. I did read that PEP but it has no relevance for my mixed Windows/Linux environments. On reflection I now believe I won't use py.exe because it introduces an unnecessary layer of indirection.The  bottom line is that you still need to know which Python a particular set of circumstances demands and if you use py.exe you then need to also understand how it chooses and how it interprets shebang lines written for your Linux environment. And if that isn't your situation I have jumped to the wrong conclusion.I have found no problem in Windows when I use shebang lines in scripts intended for execution in both Linux and Windows. They are ignored unless you use py.exe.My advice is to give up py.exe unless your use case mandates shebang lines in Windows.M--(Unsigned mail from my phone)
-------- Original message --------From: Sibylle Koczian via Python-list <python-list@python.org> Date: 14/1/24 23:59 (GMT+10:00) To: python-list@python.org Subject: Re: Python 3.12.1, Windows 11: shebang line #!/usr/bin/env python3
doesn't work any more 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-- https://mail.python.org/mailman/listinfo/python-list
--
https://mail.python.org/mailman/listinfo/python-list

Am 15.01.2024 um 00:46 schrieb Mike Dewhirst via Python-list:
> In Windows the provided methods for running complex command lines are either a batch file or a shortcut.Someone very kindly pointed out to me in this thread that there is a PEP for py.exe. I don't use py.exe originally because I didn't trust it believing it was a new-fangled Microsoft trick. I did read that PEP but it has no relevance for my mixed Windows/Linux environments. On reflection I now believe I won't use py.exe because it introduces an unnecessary layer of indirection.The  bottom line is that you still need to know which Python a particular set of circumstances demands and if you use py.exe you then need to also understand how it chooses and how it interprets shebang lines written for your Linux environment. And if that isn't your situation I have jumped to the wrong conclusion.I have found no problem in Windows when I use shebang lines in scripts intended for execution in both Linux and Windows. They are ignored unless you use py.exe.My advice is to give up py.exe unless your use case mandates shebang lines in Windows.M--(Unsigned mail from my phone)

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

Sibylle



--
https://mail.python.org/mailman/listinfo/python-list

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.

--
https://mail.python.org/mailman/listinfo/python-list

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.

--
https://mail.python.org/mailman/listinfo/python-list

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.




--
https://mail.python.org/mailman/listinfo/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:
>> 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.



--
https://mail.python.org/mailman/listinfo/python-list

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
--
https://mail.python.org/mailman/listinfo/python-list