We had a short discussion about Python 3.0 porting during our bi-weekly Python meeting at Google, and it was suggested that I write up what was discussed.
From reading the Python 3000 mailing list over the last several months, it is apparent that there are many different approaches to making the transition between 2.6 and 3.0. Some of the approaches involve source-to-source translation using the 2to3 tool, but not all of them do. A couple of different strategies have been discussed in this forum and others: -- Maintaining two parallel branches of the application, one for 2.6 and one for 3.0, and using 2to3 to keep them in sync. -- Maintaining two parallel branches of the application, and manually applying fixes to both branches without synchronizing them. -- Using 2to3 to generate a "just in time" 3.0 version as needed, but doing all development work on the 2.6 branch. There has also been some discussion of a "3to2" tool which would reverse-migrate code from 3.0 to 2.6. This could potentially be a much simpler tool than 2to3, since there are many obscure cases in 2to3 which it would not have to handle. For new code, however, there is an alternative strategy that doesn't involve 2to3 at all, which is to write code in the "greatest common subset" of 2.6 and 3.0. As Lennart Regbro pointed out earlier, this common subset is actually quite large (larger than Guido originally intended, I think), and you can write some fairly substantial applications in it. With the ability to turn on default unicode strings on a per-module basis, one of the last hurdles to effective programming in this dialect of Python has been removed. Writing code in the subset dialect will take some care, however. Many modules in the standard library have slightly different semantics in 3.0 as compared to 2.6. Some of these can be dealt with simply by avoiding legacy APIs; Others can be handled by creating a library of utility functions which isolate differences in the underlying Python implementation. So, as part of the general effort to document the various 3.0 porting strategies, what we would like to see is: -- A document describing the "common subset", and how to write programs in it. This doesn't have to be a complete standalone manual, just an addendum to the regular Python docs explaining what things to avoid and how to get around them. -- That document could include a description of (or for extra credit, an implementation of) the utility library mentioned earlier, that isolates the difference between the two Python versions. Any volunteers? -- Talin _______________________________________________ Python-3000 mailing list Python-3000@python.org http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
