On 4 Mar, 2011, at 19:56, R. David Murray wrote: > On Fri, 04 Mar 2011 15:50:01 +0000, Ronald Oussoren <ronaldousso...@mac.com> > wrote: >> On 04 Mar, 2011,at 02:21 PM, Nick Coghlan <ncogh...@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 _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
