mabshoff wrote: > > supply fixes upstream if we decide to do so. Overall we have plenty of > time for the switch because 2.x will be maintained in parallel with > 3.x for at least two years. And because we build from sources we can > pretty much switch any time we want. I would be willing to maintain an > experimental Python3 spkg that tracks Python's svn (or whatever they > use these days) closely. >
The way to go is, I think, to wait for Python-2.6 and then from http://python.org/dev/peps/pep-3000/ > Python 2.6 will support forward compatibility in the following two ways: > > * It will support a "Py3k warnings mode" which will warn dynamically > (i.e. at runtime) about features that will stop working in Python 3.0, e.g. > assuming that range() returns a list. > * It will contain backported versions of many Py3k features, either > enabled through __future__ statements or simply by allowing old and new > syntax to be used side-by-side (if the new syntax would be a syntax error in > 2.x). > > Instead, and complementary to the forward compatibility features in 2.6, > there will be a separate source code conversion tool [1]. This tool can do a > context-free source-to-source translation. For example, it can translate > apply(f, args) into f(*args). However, the tool cannot do data flow analysis > or type inferencing, so it simply assumes that apply in this example refers > to the old built-in function. > > The recommended development model for a project that needs to support Python > 2.6 and 3.0 simultaneously is as follows: > > 0. You should have excellent unit tests with close to full coverage. > 1. Port your project to Python 2.6. > 2. Turn on the Py3k warnings mode. > 3. Test and edit until no warnings remain. > 4. Use the 2to3 tool to convert this source code to 3.0 syntax. Do not > manually edit the output! > 5. Test the converted source code under 3.0. > 6. If problems are found, make corrections to the 2.6 version of the > source code and go back to step 3. > 7. When it's time to release, release separate 2.6 and 3.0 tarballs (or > whatever archive form you use for releases). > > It is recommended not to edit the 3.0 source code until you are ready to > reduce 2.6 support to pure maintenance (i.e. the moment when you would > normally move the 2.6 code to a maintenance branch anyway). > The 2to3 tool seems alreadt capable of doing a lot of changes, see the README: http://svn.python.org/view/sandbox/trunk/2to3/README?rev=57919&view=markup Don't know how cython fits in here. Jaap --~--~---------~--~----~------------~-------~--~----~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~----------~----~----~----~------~----~------~--~---
