On 4 Mar, 2011, at 19:56, R. David Murray wrote:
On Fri, 04 Mar 2011 15:50:01 +0000, Ronald Oussoren <ronaldoussoren@mac.com> wrote:
On 04 Mar, 2011,at 02:21 PM, Nick Coghlan <ncoghlan@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