Breaking backwards compatibility … the right way
I just had a chance to read Guido van Rossum’s very interesting Python 3000 status update. For those of you who don’t know yet: Python 3000 (Py3k) will break backwards compatibility. Not even an attempt will be made to preserve it.
For everyone developing a more substantial project in Python – for example we here at SnapLogic – this at first sounds quite alarming: Does everything have to be completely re-written from scratch? Fortunately, the answer is ‘no’. Guido and the other Python developers have come up with with a neat process, which should make this much easier on any software developer. It might still be a lot of work, but that process definitely is a huge help.
At the base of the migration to Py3k is Python 2.6 (yet to be released), which provides backwards compatibility, as well as access to Py3k’s features via the
__future__ statement. In addition, an automatic code conversion tool is provided. It can take Python 2.6 code and can convert it to correct Py3k code.
So, it’s easy then: Take your Python 2.4 or 2.5 code and run it under 2.6. Everything works? Fine. Now convert your code to Py3k with the automatic code conversion tool. It will give warnings and errors wherever compatibility is broken. Change code and even use
__future__ features to make the warnings go away. Try again. Once all warnings are resolved the code conversion tool will produce perfectly good Py3k code. More details about this process can be found in Guido’s original writeup.
The interesting aspect here is that it is recommended NOT to edit the automatically generated Py3k code. Instead, all maintenance should continue to happen in the Python 2.6 code. The code conversion tool will generate a fresh batch of Py3k code for you whenever you need to make any changes to the original Python 2.6 code. The benefit of doing it this way is clear: You will get Python 2.6 as well as Py3k code, essentially for free (after the initial process has been completed once). This means that your code can run on both platforms, and that you can ship code also to those who have not made the plunge into Py3k, yet. You will also not be burdened with continued maintenance of two code branches.
What a nice approach for once. How many times have we have heard lamentations in the past about how backward compatibility held back progress. A clean break and improvement was not possible because old code still needed to run. For example DOS compatibility in Windows, the Intel instruction set and other examples like this. Here with Python 3000 at least the attempt was made to make it easy for developers to move on to ‘the new thing’, while still being able to support customers that have not taken that step yet. Developers will have no reason not to support Py3k, since they can continue to support their existing customer base without too much hassle.
That’s a good thing, and I wish we would have seen more approaches like this in the past. At SnapLogic we are developing in Python. Yet again it looks like this was a good idea.