Wednesday, December 3, 2008

Is it all futile?

Today, the much anticipated Python 3.0 final was released. Truly, this is a historic release for the Python community, the first intentional incompatible Python release. It's been a long time in the making, and I applaud everybody who is responsible for proving Py3k is not vaporware. Guido and the other decision makers on Python-dev also deserve credit for not making py3k changes too gratuitous; many revolutionary ideas and features were proposed and rejected. I have every confidence that every incompatibility was well thought out. Much thought has also been given to making the transition as easy as possible for the community. The suggested migration path, fixing Py3k warnings in 2.6 and then applying 2to3, has been used with a fair amount of success on several projects. We've even had several Py3k love letters!

Still, I can't help being a little worried. I think the bytes and str divide will be difficult for people especially with IO where everything has to be dealt with in bytes. We may see many "x.encode('ascii')" lines popping up all over codebases. Userland libraries will need to maintain compatibility with 2.4 and 2.5 for a while; that significantly complicates the dream of maintaining just one branch for 2.x and py3k. 2to3 is not even close to perfect and will only correct the surface incompatibilities of syntax between the versions. I'm also concerned about burn out. The excitement of a new major version will certainly spur an interest in porting for a few months, but I suspect it won't be so fun after the aura wears off a bit. I hope common base libraries (PIL, Twisted, lxml, etc...) are ported soon. It will build the bridge for everything else to cross over too.

Of course, what I'm forgetting is the amazing Python community. Whatever the results, a new era has certainly begun. We just need time.

1 comment:

Michael Watkins said...

I don't think the effort is futile, quite the contrary. Its a nice step forward - not revolutionary, but packed with nice changes and cleanups.

Migrating packages might prove to be a challenge but if they were designed well from the start, it ought not to be that difficult. As an example, QP and Durus, a full web application and database development package, including a Python object database rather like ZODB, has already released a 2.x and 3.x compatible release on the same code base.

I did some testing work on this over the last couple of months and can report that wholesale change was not required; there aren't many "compatibility shims" in the code to deal with 2 and 3 from the same code base.

Regarding the new string and data/bytes concept, I think people will like it so much they'll feel a little miffed about having to go back to the old way of doing things. And the QP example shows that if their input and output code bits are well isolated from the rest of the application, making a switch doesn't have to be horrible effort.

Certainly you've hit the nail on the head regarding packages - ultimate success requires those packages we've all come to love and rely upon to make the journey to 3. Hopefully the community will embrace the change. I'm personally hoping that docutils is one of the first - moving tools many of us use to document our work with ought to be something of a priority I think / hope.