On 3/24/20, Barry Scott <ba...@barrys-emacs.org> wrote: > > If you have python 2 and 3 installed then > > py -3 myscript
"myscript" may have a shebang that runs the "python2" virtual command (e.g. "#!python2" or "#!/usr/bin/python2") because the script requires 2.x, but using "-3" will override it to run the "python3" virtual command instead. The "python2" virtual command defaults to the highest installed version of 2.x. The "python3" virtual command defaults to the highest installed version of 3.x. Without a shebang, the "python" virtual command defaults to the highest installed 3.x, but with a shebang it defaults to the highest installed 2.x. py without a script (e.g. the REPL or -c or -m) uses the "python" virtual command, so it defaults to the highest installed 3.x. The version to run for the "python" virtual command is set via the PY_PYTHON environment variable, whether or not there's a shebang. Similarly the version to run for the "python2" and "python3" virtual commands is set via PY_PYTHON2 and PY_PYTHON3. No sanity checks are performed, so "PY_PYTHON2=3" is allowed. >> #! /usr/bin/env python3 > > This does work out of the box because py.exe is run when you execute a .py > in the CMD. The "/usr/bin/env" virtual command is expected to search PATH. py does search PATH for "/usr/bin/env python", but for "/usr/bin/env python3" it uses the "python3" virtual command instead of searching, since standard Python installations and virtual environments do not include "python3.exe". There's an open issue for this, but there's no consensus. > You can check by doing: > > assoc .py > ftype Python.File > > If Python.File is not using py.exe then you can fix that with this command > from an Admin CMD. > > ftype Python.File="C:\windows\py.exe" "%1" %* CMD's internal assoc and ftype commands are no longer useful in general. They date back to Windows NT 4 (1996) and have never been updated. As far as I know, Microsoft has no up-to-date, high level commands or PowerShell cmdlets to replace assoc and ftype. In PowerShell I suppose you could pInvoke the shell API (e.g. AssocQueryStringW). assoc and ftype only access the basic system file types and progids in "HKLM\Software\Classes", not the HKCR view that merges in and prefers "HKCU\Software\Classes" or various other subkeys such as "Applications" and "SystemFileAssociations". Also, they don't account for the cached and locked user choice in the shell. For example, assoc may tell you that ".py" is associated with the "Python.File" progid. But it's potentially wrong. It's not aware of an association set in "HKCU\Software\Classes\.py" (e.g. set by a per-user Python installation). It's also not aware of a locked-in user choice (i.e. the user selected to always use a particular app), if one is set, in "HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\FileExts\.py\UserChoice". The user should set the file association using the settings dialog for choosing default apps by file type or the "open with" dialog on the right-click context menu. If the application chooser doesn't include a Python icon with a rocket on it, then probably the launcher and Python.File progid are installed for all users, but there's a per-user association in "HKCU\Software\Classes\.py" that's overriding the system setting. Deleting the default value in the latter key should restore the launcher to the list of choices. _______________________________________________ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/C3ZH4TZLN3APOF3PVSEEZM6XIVCIIFVG/ Code of Conduct: http://python.org/psf/codeofconduct/
