Openning Python program

[Eryk Sun]

On 2/6/22, Dennis Lee Bieber <wlfraed at ix.netcom.com> wrote:
>
> NOTE: there may be a "launcher" installed that is supposed to find Python
> without requiring one to edit the system PATH environment variable -- but I
> tend to avoid it: M$ and some other applications seem to keep hijacking
> which Python gets priority, and it often invokes anything but the version I
> want. [If on installs Visual Studio and doesn't read carefully, it will
> install its version of Python and the R statistics system] (Though it
> appears that today is a good day...)

No other applications have anything to do with how the py launcher
works. It depends on the Python installations that are registered in
the "Software\Python\PythonCore" registry key in HKCU and HKLM. If the
launcher is installed, the command template of the "Python.File"
ProgID is configured to use the launcher, e.g. `C:\Windows\py.exe "%L"
%*`. Whether or not other applications take control of the ".py" file
association, and whether the user allows this to happen, is a separate
issue.

Unless the launcher is configured otherwise, or the version to use is
set by a shebang line in the script, the launcher defaults to running
the highest version number of Python that's installed. If there are
multiple installations for the same version, it prefers the system's
native architecture (e.g. x64 in 64-bit Windows). You can list the
available versions and paths via `py -0p`.

The launcher allows setting the default version to use, and also
separate defaults for 2.x and 3.x (i.e. for the `-2` and `-3`
command-line options). This is simplest to set via the PY_PYTHON,
PY_PYTHON2, and PY_PYTHON3 environment variables, but it can also be
configured in "%LocalAppData%\py.ini".

 > NOTE: I have Windows configured to accept .py as an executable file, with
> the Python interpreter as the "runner", which is how the lines without
> "python" function -- but if you explicitly invoke python with a file name
> you must provide the full name.
>
> C:\Users\Wulfraed>assoc .py
> .py=Python.File
>
> C:\Users\Wulfraed>ftype python.file
> python.file="C:\Python38\python.exe" "%1" %*

The CMD shell's ASSOC and FTYPE commands are out of date and should
not be relied on. The returned or set values from those commands are
often irrelevant to what the shell API actually does.

ASSOC and FTYPE operate on only the "HKLM\Software\Classes" setting
(i.e. file associations set for the machine), which was sufficient
when these commands were added in Windows NT 4.0 (1996). But since
Windows 2000, HKCR is a merged view that prefers values set in
"HKCU\Software\Classes" (i.e. file associations set for the current
user; e.g. Python is installed for the current user).

Also, Explorer caches file associations per the user's last "open
with" choice in
"HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\FileExts".
When the shell API computes the file association for a file, this user
choice overrides the HKCR settings. Moreover, the user choice for each
association in the shell's "FileExts" key can be locked down in its
"UserChoice" subkey (i.e. the user opted to always open with the app).