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

[Ronald Oussoren]

On 4 Mar, 2011, at 19:56, R. David Murray wrote:

> On Fri, 04 Mar 2011 15:50:01 +0000, Ronald Oussoren <ronaldoussoren at mac.com> wrote:
>> On 04 Mar, 2011,at 02:21 PM, Nick Coghlan <ncoghlan at gmail.com> wrote:
>> 
>> For *nix, I think there is a simple way forward that is an improvement
>> over where things stand now. For Windows, I don't think we can do much
>> better than the status quo and for Mac OS X... I think Apple will do
>> whatever Apple feel like doing :)
>> 
>> Apple will generally follow what we decide to do for the base install.
>> 
>> Anyway, I'd say that OSX should do the same as Unix platforms here and support
>> '#!/usr/bin/env python2'. Adding another symlink is fairly trivial.
> 
> FYI, Ronald, the text version of your emails looses all quoting
> information.  It would be nice if you could use standard email
> quoting (leading '>' characters).

Sorry about this, I keep forgetting how crummy the webmail interface of mobileme is in that regard.

> 
>> P.S. I'm a bit confused about this discussion though, wouldn't adding python2 to
>> the installation be a feature change and as such not something that can be done
>> in a maintenance branch?
> 
> The purpose of the "no new features" rule is to prevent the situation
> where a piece of code written for X.X.2 fails to run on X.X.1 because
> it relies on a feature introduced in X.X.2.  In this situation, we
> *already* have failures because scripts using /usr/bin/python2 that
> run on one distro won't run on a different distro where that symlink
> isn't defined.  In this case I don't think the "no new features" rule
> can be applied blindly, because the feature has *already been introduced*
> by third parties.  What we are attempting to do is make it *more* likely
> that things will work in the future.

This is a new feature for the cannonical distribution, no release on python.org will install a binary named 'python2'. Adding one now will result in a clear change in behaviour: "#!/usr/bin/env python2" will work in 2.7.2 while it won't work with 2.7.1. That it happens to work right now with some python distributions doesn't mean this isn't a new feature, it's just another instance where the linux distribution maintainers think they know better than the developers.


> 
> You can argue that having /usr/bin/python2 installed by 2.7.2 means
> that code written for 2.7.2 that relies on it won't run on a vanilla
> user-install of 2.7.1 or 2.7.  But how likely is that scenario compared
> to the scenario where a script written for another distro fails to run
> because /usr/bin/python2 doesn't exist?  I think the balance of the
> argument comes down in favor of making the change, personally.

That depends on the distributions that have /usr/bin/python2 and change /usr/bin/python to be python3. IIRC the discussion only mentioned Arch Linux and Gentoo, which are AFAIK not major distributions. I'm personally unlikely to run into a distribution that has a broken /usr/bin/python anytime soon, most linux code I write runs on enterprise distributions and those aren't known for being frontrunners with changes like this ;-)

BTW. I'm +0 on the change, having python2 can be useful and while this is a new feature it doesn't require major changes when backporting scripts to previous patchlevels.

Ronald