Python aliases under Windows?

[Kirill Balunov]

2018-04-03 22:04 GMT+03:00 eryk sun <eryksun at gmail.com>:

> On Tue, Apr 3, 2018 at 3:43 PM, Ian Kelly <ian.g.kelly at gmail.com> wrote:
> >
> > Because py.exe is really meant to solve a slightly different problem.
> > On Unix if you have a .py script and you run it directly, without
> > specifying which interpreter to use, the convention is to start the
> > script with a shebang line, and the kernel will transparently use the
> > interpreter specified there. Windows, however, doesn't respect shebang
> > lines and instead associates programs with files by file extension.
> >
> > Here's the problem: Python 2 files have a .py extension. Python 3
> > files also have a .py extension. Windows doesn't allow both Python
> > binaries to be associated with the same extension. So how can we set
> > things up so that launching a Python file will invoke the correct
> > Python version? To solve this, Python ships with py.exe and associates
> > *that* with the .py extension. py.exe knows what Python versions are
> > installed, and it inspects the shebang line to decide which one to run
> > for this particular script.
> >
> > The fact that py.exe can also intelligently select versions from
> > command line arguments is just an added bonus.
>

Thank you Ian, Terry, Eryk! Now I understand the purpose of py launcher in
general. I don't have Windows near, will `py -3.6 ...` work if Python36 is
not on the Path? If not, it seems to me, that if `python3.exe` and
`python3.6.exe` were provided they would be equivalent, and together they
will complement together and unify UNIX and Windows workflow. Am I missing
something?


> Alternatively, there's the Windows Script Host (WSH) framework
> (cscript.exe console, wscript.exe GUI), which supports a generic WSF
> file extension that allows mixing multiple languages in a single
> script, and integrates with COM, ASP, and native debuggers. PyWin32
> supports WSH. This could have been adapted to support Python 3 as a
> separate Windows scripting engine.
>
> That said, for general use, the py launcher's registration+shebang
> support is more flexible than the WSH registration-only approach. The
> launcher supports virtual Unix shebangs for cross-platform scripts and
> arbitrary executable paths for scripts that depend on virtual
> environments. I use it for the .py[w] file association and creating
> virtual environments. I still prefer `python` on the command line.
> Even on Linux I don't frequently use `python3` or `python3.X`. I do
> very little with the system Python.
>
> If you really miss typing "python3.6", I suggest using relative
> symbolic links (e.g. CMD's `mklink` command) created in the same
> directory as python[w].exe. Using relative symlinks requires
> installing Python on a NTFS volume that supports them, so it's not a
> viable solution for external drives that use FAT32 or exFAT. In the
> latter case, an alternative to batch scripts is to create a
> "python[w]3.6.lnk" shell shortcut to "python[w].exe". Leave the "start
> in" folder empty, so it will inherit the parent's working directory,
> and add .LNK to the system PATHEXT environment variable. One caveat is
> that, unlike symlinks or batch scripts, executing shell shortcuts
> requires ShellExecute[Ex] (called from Explorer, CMD, PowerShell,
> etc). CreateProcess (e.g. subprocess.Popen with shell=False) doesn't
> know anything about .LNK files.
> --
> https://mail.python.org/mailman/listinfo/python-list
>

Thank you for your detailed advice, I'll try to understand. Why under
Windows everything is so complicated... Concerning dealing with `python` vs
`python3` it is a matter of habit, and I find the latter option more
reliable and missing it under Windows.

With kind regards,
-gdg