On 4/1/23, Barry Scott <ba...@barrys-emacs.org> wrote:
>
> I find user environment on windows to be less flexible to work with then
> adding a py.ini. On my Windows 11 I added
> %userprofile%\AppData\Local\py.ini.
> To make python 3.8 the default that py.exe uses put this in py.ini:
>
> [defaults]
> python=3.8-64
> python3=3.8-64
Using "py.ini" has the advantage that launcher always reads the file.
The value of the environment variables, on the other hand, may be
stale. If you keep a lot of shells running, it would be tedious to
have to manually update the PY_PYTHON* variables in each shell. That
said, it should be rare that one needs to change the persisted default
versions. For temporary changes, the PY_PYTHON* environment variables
are more flexible and take precedence over "py.ini".
If one doesn't use "py.ini" to set the defaults, it's easy to modify
the persisted user environment using "setx.exe"[^1]. For example:
setx.exe PY_PYTHON 3.8
setx.exe PY_PYTHON3 3.8
setx.exe broadcasts a WM_SETTINGCHANGE "Environment" window message,
which causes Explorer to update its environment. Thus any program run
from Explorer will see the new values. A program launched in a new tab
in Windows Terminal also gets a fresh environment. However, existing
CLI shells (CMD, PowerShell, bash), and programs started by them, will
still have the old environment values. The latter is where using
"py.ini" to set the defaults has the advantage.
---
[^1]: Note that "setx.exe" should never be used to set the persisted
user or machine "Path" value to the current %PATH%. When loading the
environment, the user "Path" gets appended to the machine "Path".
Setting the entire expanded and concatenated value to one or the other
leads to a bloated, redundant PATH value, and it also loses the
flexible configuration based on REG_EXPAND_SZ values.
--
https://mail.python.org/mailman/listinfo/python-list
