Guido van Rossum recently made the slides from his talk on Python 3000 at ACCU 2006 available for download. I was not at ACCU 2006, but I did see Guido give a practice run of the same talk a few weeks ago at a local ACCU meeting in San Jose. In this talk, Guido discussed the philosophy and features of Python 3000, a major new version of Python that will be developed alongside the current stream of 2.x versions. One of the main bullet points on Python 3000 philosophy is:

• Allow incompatible changes; within reason

When developing new versions of languages and published APIs, maintaining backwards compatibility is usually one of the designer's main concerns. By maximizing backwards compatibility, the designer minimizes the cost for existing users of the language or API to upgrade to the new version. However, with each new release there are invariably changes that would improve the design, but which would break backwards compatibility. Over time, always choosing backwards compatibility over design improvement means that entropy creeps into the language or API. This entropy too has a cost: the language or API becomes more complex and confusing for developers to use.

One of the most basic kinds of breaking change a designer can make in a new version is to remove features that had been deprecated in previous versions. For example, Python 2.2 introduced "new-style" classes, to provide Python with a unified object model with a full meta-model. Old-style classes, which starting with version 2.2 were referred to as "classic" classes, were still supported for backwards compatibility. The intention was that new code, however, should use new-style classes. One of the first thing Guido did on the Python 3000 codebase was remove classic classes. "It felt good to rip them out," he said.

New versions of Java have made breaking changes at the source level too. For example, the introduction of the assert keyword in version 1.4 broke code that used assert as a variable or method name (such as just about any JUnit TestCase, whose calls to assert() needed to be changed to assertEquals()). Nevertheless, my observation is that the Python community has been more willing to accept breaking changes than the Java community. As Guido put it, "Java has a very long backwards compatibility cycle." Many methods in the Java API have been deprecated, but I know of none that have been actually removed. The result is that Java over time has become more and more bloated with historical design artifacts, while Python remains more lean, mean, and clean.

What do you think is the correct tradeoff between backwards compatibility and entropy reduction for Python and Java? Does Python go too far to clean things up from release to release? Does Java not go far enough?

i/j -> olddiv(i,j)

where

def olddiv(i,j):
    if isinstance(i,int) == isinstance(j,int):
        return i//j   # floor-division
    else:
        return i/j

Integer.getInteger(String nm) 

for(INSTANCE element:theFirstSet){
    if(theSecondSet.contains(element){
        tempSet.add(element);
    }
}
return tempSet;

firstSet.intersect(secondSet);