Michael: the 3.0 Makefile warns severely against i...
Guido van Rossum · 2008-12-05T15:23:00
Michael: the 3.0 Makefile warns severely against installing as "python" (and you have to use a different command to do it). Now you know why.
Red Hat had the same problem when 2.0 came out -- their install scripts only ran with 1.5.2. This was solved by keeping 1.5.2 the default and using "python2" for 2.x.
I expect vendors to do a similar thing for 3.0, though I personally would prefer it if people used
Guido - agreed. I'd switched mine intentionally as I've been doing quite a bit of testing on 3.0 while helping to get a package released for 2.x and 3.0. But I did forget about the *nix package management issue.
I've never released a "port" for the FreeBSD Ports system but will do one just to see what the issues are. I don't know how other packages have dealt with dependencies when a major rev comes along. It may particularly tricky when a python package can support both 2.x and 3.x from the same code (which isn't always going to be evil).
I guess for now defaulting to requiring 2.x in such a case is the right thing to do, if Python is not already on the system, and if both are on the system, leave it to the sysadmin to adjust.
As for 3, I really am enjoying the cleanup, beyond just the great improvements with unicode / text / data. Folks that deal with unicode are going to find Python 3 very refreshing. Tastes great, less filling too!
One thing I'd not considered is the impact on (U|L...
Michael Watkins · 2008-12-04T22:37:00
One thing I'd not considered is the impact on (U|Li)nix distributions and their package management:http://mikewatkins.ca/2008/12/04/python-3-system-side-effects/
Already a web application framework ported/updated in "2 and 3" style:
http://mikewatkins.ca/2008/12/03/first-python-3-web-application-framework/
Michael: the 3.0 Makefile warns severely against i...
Guido van Rossum · 2008-12-05T15:23:00
Michael: the 3.0 Makefile warns severely against installing as "python" (and you have to use a different command to do it). Now you know why.Red Hat had the same problem when 2.0 came out -- their install scripts only ran with 1.5.2. This was solved by keeping 1.5.2 the default and using "python2" for 2.x.
I expect vendors to do a similar thing for 3.0, though I personally would prefer it if people used
#! /usr/bin/env python3.0
as the first line of their script.
Guido - agreed. I'd switched mine intentionally as...
Michael Watkins · 2008-12-05T16:30:00
Guido - agreed. I'd switched mine intentionally as I've been doing quite a bit of testing on 3.0 while helping to get a package released for 2.x and 3.0. But I did forget about the *nix package management issue.I've never released a "port" for the FreeBSD Ports system but will do one just to see what the issues are. I don't know how other packages have dealt with dependencies when a major rev comes along. It may particularly tricky when a python package can support both 2.x and 3.x from the same code (which isn't always going to be evil).
I guess for now defaulting to requiring 2.x in such a case is the right thing to do, if Python is not already on the system, and if both are on the system, leave it to the sysadmin to adjust.
As for 3, I really am enjoying the cleanup, beyond just the great improvements with unicode / text / data. Folks that deal with unicode are going to find Python 3 very refreshing. Tastes great, less filling too!
Page 1 of 1
Back to post