[Python-Dev] Python-3000 upgrade path

[glyph at divmod.com]

On Sun, 25 Feb 2007 13:12:51 -0800, Thomas Wouters <thomas at python.org> wrote:
>I'm sending this to python-dev instead of python-3000 for two reasons: It's
>not about features to be added to Python 3.0, and it's not really
>about 3.0at all -- it's about
>2.6 and later. It's about how we get Python 2.x to 3.0, and howmuch of
>3.0we put into
>2.6 and later.
 ...
>I also don't mean doubts about how we're going to keep the
>performance impact minimal or how we're going to handle dict views and what
>not. I mean doubts about this procedure of having transitional releases
>between 2.5 and 3.0, and the *community* impact of 2.6+ and 3.0 this way.

I'm pretty tired at the moment, fried from PyCon, and have a lot of work to catch up on, so I'll have to spend a while collecting my thoughts to respond in more depth.  However, especially since I've been a vocal proponent of a strategy like this for a while, I would like to say that I'm basically happy with this.  Not only that, I'm significantly relieved after PyCon about the difficulty of the migration, and confident that, if my current understanding is correct, Twisted _will_ support 3.0 and beyond.

Effectively, what this plan means is that the most *basic* aspects of transitioning to Python 3.0 should work like the transition to any other new Python release.  More changes may be necessary, but it should be possible to add a few restrictions to your codebase, and continue to supporting older releases with little trouble.  Transitioning to 2.5 was a fairly rocky upgrade for Twisted as well, though, and we made that one reasonably well.

The one concern I have is that there are things the source translator won't do correctly.  That's fine, but I think there are two important technical features it really needs to make the social aspects of this upgrade work well.

2to3 should take great care _tell_ you when it fails.  One concern I have is that the source translation may subtly alter the *semantics* of unit test code, so that the tests are no longer effective and do not provide adequate coverage.  I think this is an extremely unlikely edge case, but a very dangerous one in the event that it does happen.  I don't know of any bugs in 2to3 that will do this at the moment, but then it's hardly the final release.

Also, the limitations of 2to3 should be very well documented, so that when it does tell you how it has failed, it's clear to the developer what changes to make to the *2.6 source* to cause it to translate correctly, not how to fix up the translated 3.0 code.

Thanks *very* much to all the python core developers and community members who have been working to make this happen, especially to Neal, Thomas, and Guido for listening intently to all of our concerns at PyCon.