At the end of my talk yesterday, one of the attendees pointed out that Python 3.0 was released that very same day. In joking fashion, he asked, “Do you support it?” I chuckled and did explain that currently we were supporting 2.4 and 2.5 because essentially, that is what I have personally ran the automated test suite against. I hadn’t been able to run it against 2.6 yet, but intend to do that at some time. I would like to cover as much as possible, but there will definitely be limits to what is possible with a single baseline. Of course this begs the question: what DO you do when you hit that limit?
We need to determine how much interest there is, because it will demand we maintain multiple branches of Spring Python. That gets costly. I discussed this point over lunch with Russ, and he agreed with me that our primary interest is to support production systems. I believe that most people are NOT jumping rapidly to Python 3.0, so…why should we?
This is the same problem Spring Java has to deal with in regard to supporting Java 1.3, 1.4, 5, and 6. Spring 2.5 is currently supporting Java 1.3-1.4 with most classes. They also have additional classes to support Java 5/6. However, Spring 3.0 is going to move up to Java 5 and drop support for the older JVMs. This gives them the space to remove some older code, make other code fully utilize generics, etc. Like always, if you buy a support contract, SpringSource will certainly support you on an older JVM. But, they can’t hold the entire framework up forever, so they are following what the industry is using, any many have moved up to Java 5.
Likewise, Spring Python is following the Python industry, and Python 3.0 is a little too new. Don’t get me wrong. We’ll check it out. Perhaps it works out of the box for us, because we haven’t used too much yet. Still, there are lots of features we want to get implemented that are way more pragmatic and useful than supporting Python 3.0.