Even though I am on vacation this is worth a quick note. After long efforts by many developers Python 3.0 was released today!
I posted a short article a while ago about 3.0 (in)compatibility, but the differences between 2.6 and 3.0 aren't so great. It's perfectly possible to write 3.0 code that will run on 2.6 too, as most of the language hasn't changed at all.
The preferred strategy for writing code that runs on both versions is to write in 2.6 and then apply the 2to3 converter and verify that it produces a correct 3.0 program. There's no guarantee that it will, so you may need to paraphrase the 2.6 code a few times before you get a transatable program.
Once all the third-party modules you and extensions you rely on are 3.0-ready, and you no longer have clients requiring 2.6 version of your software, you can simply drop the 2.6 compatibility requirement and start to make use of the few 3.0-only constructs that have been introduced.
"Any sufficiently advanced technology is indistinguishable from magic" -- Arthur C Clarke
Musings from the technological frontier
3 comments:
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 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 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!
Post a Comment