Posted by: sourceoffailure | August 10, 2008

Agile ’08 and the Home Strech

I thought I would be blogging more, but hey, life gets busy. And as one Adam @ Home comic strip put it, some days, “I don’t have anything to blog about.”

Microblog: After learning about and developing new skills at the Agile Conference in Toronto, Canada, I look forward to applying the techniques and information I’ve learned, especially in User Experience (UX), to new projects (or old projects, or DrProject -.-) in the fall. The first round of testing of DrProject’s NEWT milestone is complete (as testing/designing and coding are in a two-step), and now I am processing LaTeX into Markdown for Greg Wilson’s CSC301 informal textbook.

Microblog 2, directed at Python 3.0: I want to explore in the paragraphs below how I think that Python has shot itself in the foot and how I might have simple solutions, some of which has been practiced in other languages.

Python, in the last few years, has become a highly respected and stable language. Reports expect that 15% of Google’s codebase is written in Python (1). However, with the expected release of Python 3.0 comes reports that previously written Python scripts will be incompatible with new ones, and that brings a lot of problems with it. Python, in essense, has just shot itself in the foot.

Part of the conventions of programming languages is that you do not break someone else’s code when the compiler changes. Java is an excellent example. Sun may, from time to time, depreciate various methods and practices. In this case, the code does not completely break, but in a compile error, says that the user is calling a depreciated method. Also, Sun elects to still display the javadoc for these old methods, even if they are not ment to be used any longer.

Although Guido deserves some reprieve for attempting to increase the simplicity of Python coding (likely in the face of it’s similar competitor, Ruby), this experiment jeopardizes the credibility of the programs produced wth Python (some which certainly have influence in business) and will lead to utter chaos and hassle of maintaining more then one distribution of Python on a single system, particularly to users who are not familliar with Python, or with programming languages in general. Those users expect backward compatible behaviour.

So, what to do?  I propose three solutions:

0. If the language is going to experience a substantial shift, create a new language and change its name. Cobra anyone?

1. Adaptive refactoring. This is the same practice as Sun used for the getGraphics() method in the AWT. Originally, the getGraphics method of a component to draw objects on the screen. Now, get2DGraphics() is used. getGraphics is now simply a wrapper for the new method. Python could also do a simmilar process, which allows the use of both processes to access the same thing. Another part of this is based on the blackbox techinque. Describing the interface for something is much more efficient then describing its interals. Perhaps midway – in an agile development team – an efficency is noticed that will allow a refactoring of code. Concealing that refactoring until the next release with wrapper methods ensures that other people’s code does not break because you have redesigned your interface.

2. Depreciation, Support, and Final Removal. Old methods are depreciated but still supported within the language, and after a certain amount of time, are finally removed as they expect code that is still in use will not use such methods.

3. Versioning. This option is more of a preventative feature, but versioning the file to a specific compiler would prevent compiling 2.x code with a 3.y compiler and is much more helpful to the user instead of saying that a method that was expected to be there is now missing.

Python has just shot itself in the foot with its plans in the 3.0 release. But it doesn’t have to. There are three main ways that the language can keep out of trouble: Adaptive Refactoring, Depreciation, and Versioning. And if that is not enough, if the language itself is going to experience an earthquake of a shift, then simply change it’s name just like other projects. The last thing we need is broken code. We have enough of that already.

That is a source of failure.

Source (1):,breaking-the-python-code.aspx


This is the home stretch. The final week.



  1. Guido also deserves much reprieve because the whole 2.x series, which spanned several years, was all about maintaining compatibility while still pushing the language forward. However, there is only so much one can do before legacy architecture constraints must be broken to improve the *language*.

    Some of the issues that Python 3.0 addresses run much deeper and are more subtle than simple library calls. For example, unifying types and classes.

    On the other hand, if Python 3.0 is going to break some compatibility, it could have been an opportunity for some real improvements like language-level unit testing and optional static type checking. Alas, most Python 3.0 discussions start out with “print is now a function”. Zzzzzz….

    Your post caught my eye because it mentions “Cobra anyone?”. Well, yes, indeed! I am the author of the Cobra programming language which has the above features and then some. I think it’s a more exciting offering than Python 3.0.

    It’s also open source and you can decide for yourself.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s


%d bloggers like this: