[Python-Dev] Support the /usr/bin/python2 symlink upstream

[Nick Coghlan]

On Sat, Mar 5, 2011 at 8:04 AM, Glenn Linderman <v+python at g.nevcal.com> wrote:
> The really tricky part on Windows is handling file associations. I
> think we're just doomed on that front, unless we want to start
> supporting separate .py2 and .py3 extensions (and adding *that* in a
> maintenance release would be a far cry from just adding another
> symlink).
>
> Supporting .py2 and .py3 extensions is not much harder than adding a
> symlink.  Easier, on versions of windows without symlinks :)
>
> Sadly, Vista (I think) and 7 (for sure) restrict the  "assoc" and "ftype"
> commands with = signs, to being functional only in "Run as Administrator"
> shells, so on those versions, it is harder for the naïve to do the
> reconfigurations themselves.
>
> The extra ftypes and assoc definitions can simply be copied from the
> existing ones, adding or changing a version number.  Would be much nicer if
> the installer did it for the naïve Windows user.

That's not the tricky part I was talking about - if .py2 and .py3 work
as scripts, the question arises as to whether or not they should work
as modules as well. The precedent set by .pyw is that they would, but
that then runs headling into Martin's question of how to spell
combinations of "w" with "2" and "3".

> For Windows the status quo is pretty bad, so doing nothing is also pretty
> bad.  I agree the changes are "harder than an extra symlink" on Windows, but
> for someone that understand the installer, adding extra ftype and assoc is
> no harder, as it already knows how to install/replace that for .py files.

The key point for me is that the changes needed to significantly alter
the situation on Windows are far too invasive to be considered in a
maintenance release. A separate PEP proposing changes in this area for
Python 3.3 and later may be acceptable (especially if MvL is willing
to act as BDFOP*), but there really isn't a lot we can do for older
versions that is sufficiently low impact to justify breaking the "no
new features" rule.

Cheers,
Nick.

* Benevolent Dictator For One PEP, Guido's scheme where he delegates
the "accept or reject" decision for a given PEP to someone else.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia