Don't Use Python 3.0? Really?

It's difficult to say "don't use Python 3.0" without being rude to the developers, as the code seems to be of very high quality. Now that Python 3.0 is almost here (release candidate 2 is a week old as I write) we should encourage people to use it, but only under well-defined circumstances. Here is some text I put together for inclusion in the release notes, to give people guidance about when and why it is and isn't appropriate to use 3.0. I would welcome further ideas to refine this text.

Readers should note that this release has significant backwards incompatibilities with the 2.X series, both at the language level and also in the C APIs available to extension module authors. These have been introduced by design, with the goal of improving the language in the long term, but this situation has implications for production use.

Furthermore it is likely that there will be a considerable delay before some authors of Python packages and extension modules start to provide 3.0-compatible releases. There are significant hurdles to be overcome in migrating extension modules from Python 2 to Python 3.

For these reasons you are NOT recommended to rely on Python 3.0 as your main production Python implementation until you know that all supporting code is available in compatible forms. While every care has been taken in the production of the Python 3.0 release, and the release team feels that the system is of a quality comparable with the recently-released Python 2.6, the latter system is currently the recommended version for production use.

I hope that clarifies things, but I would welcome further ideas to refine this text and make it more helpful. One of the primary reasons for using 3.0 is to get a migration strategy ready. But 3.0 is undoubtedly not for everyone, at least not just yet.

Python 2.6 Released

Thanks to release manager Barry Warsaw and a cast of thousands! Get it from the usual place.

Python 2.6 First Release Candidate Due Today

To maintain the fairly aggressive release schedule Barry Warsaw and the Python developers have decided to decouple the 2.6 and 3.0 releases, so 3.0 will now be slightly delayed - maybe by a couple of weeks. This gives them the freedom to bring out 2.6rc1 today, with the intention of brings 2.6rc2 out on Wednesday September 17 as originally planned, and hitting the October 1 final release date.

Since 3.0 isn't intended for production work I think this decision is the right one. There are still a few release-blocking issues on the 3.0 code, and there's little point trying to release it before quality is acceptable.

It will be great to see the next new release of Python. If you have any chance at all to test the release candidates you too can help to improve the quality of the eventual release.

Django 1.0 Alpha 1 released

We learned yesterday that the Django development team had released the first alpha on the trail to the 1.0 release due early in September.

This is great news: it means that the major items that have been developed on the sidelines (a refactoring of the queryset code and a rewrite of the admin application to use NewForms) are now fully merged into the trunk. Most of the functionality for the eventual release is now in place, though of course the feature freeze doesn't start until the betas, scheduled for two weeks time.

CPython Getting Serious About Quality: Help Needed

Beta2 of Python 2.6 and 3.0 was due out today. It isn't going to happen, and for the best of reasons. Under the guidance of release manager Barry Warsaw the developers have started to pay serious attention to the output of the buildbots, the systems which perform continuous integration testing of the development version of the Python interpreter.

Barry has just announced that there are three issue serious enough to delay the release, even though this potentially means slipping the release schedule (though time will tell whether that's a serious concern). If you are a Python developer, please take notice of what he said in an email to the python-dev list earlier today:

Please everyone, if you have only a little bit of time to work on Python, I hope you will attack the release critical and deferred blocker issues, and work on turning the buildbots green.  These are the top priorities in order to get 2.6 and 3.0 out on time.  And just as added incentive, our October 1st goal is being noted by downstream vendors. [Possibly confidential information about third parties redacted].

Quality is important. Please do whatever you can to help. Many people can benefit from a little extra effort now.

Django Nudges Closer to 1.0

Malcom Tredinnick just announced that he has merged the long-awaited queryset-refactor branch into the Django trunk. This puts one of the major blocks in place for the 1.0 release.

James Bennett recently posted his list of requirements for a 1.0 release (with a warning that suggestions from twits would not be tolerated: do not annoy this man if you don't know what you are talking about), and this announcement reduces the length of the list to eleven items.

So it's got significantly closer, as queryset-refactor was a biggie. Now I have to go test my code against the new branch ...

Resolver Released

In yet another piece of good news for Python fans, Resolver Systems have released their first product. It's a spreadsheet that you can manipulate in Python, and it's received a lot of interest from the financial communities on both sides of the Atlantic. [You would not believe how much of the world's financial dealing is controlled and managed by spreadsheets; it's really quite scary].

Resolver One is written in IronPython by a team which includes the Fuzzyman (occasionally also known as Michael Foord), of Voidspace Techie Blog fame, and it's currently the largest product developed in that languages, with a total codebase (including tests) of over 100 kloc. The company is bravely making the product available (though not, I believe, as open source) free for non-commercial use.

Mike and other members of the Resolver team will be at PyCon in Chicago in March, which is yet another reason to attend this most excellent conference. Registrations will, I am assured, be open by the beginning of next week--I have already secured my place by acting a test subject of the registration process, and will attempt to stay for a couple of the sprint days too this year.

Yet Another Longhorn Delay

Why don't Microsoft just stop announcing product plans? Their releases inevitably turn out to be later than anticipated, and the resulting back-pedaling just makes them look like bad planners.

As you might have read, the Microsoft Server Division Blog has detailed another delay - it now looks like Windows Server 2008 will actually be released in 2008 (assuming they manage to avoid another 9 months of slippage).

It's interesting that the explanation for the delay tries to mask the fact that Microsoft are apparently not yet satisfied with product quality. If the quality of some earlier products is anything to go by then it doesn't bode well for Server 2008. Still, nobody said running the largest software company in the world would be easy.

Buildbot Machines Wanted

I know there are quite a few hosting companies now who represent themselves as Python-friendly. Rather than trawl through the Wiki pages, however, and email each one separately I am sending this request to the comp.lang.python list (and putting it on my blog) in the hope of attracting those companies who are more involved with the Python community.

There is a particular problem, highlighted recently by this comment from Dennis Lee Beiber:

Too many 3rd-party modules still aren't available in 2.5 versions for my tastes...

This applies particularly (though not exclusively) to the Windows platform, for various reasons -- the most common one is that Linux developers frequently don't have a Windows machine available to help them test their builds and ensure that distributions are available.

I am trying to address this problem, initially by making hosted Windows machines available for use as buildbots. I already have agreement from Grig Gheorghiu (who maintains the PSF's buildbots) to try and support these efforts, and from Microsoft to consider providing appropriate software.

What I don't have is hosting companies offering me space on machines in their racks. If anyone reading this can help out I'd appreciate it if they would get in touch with me (replying to the newsgroup post or commenting on the blog entry should do it). These machines would need remote desktop access so they could be managed without physical presence.

The intention is to try and shorten the "version lag" so that new versions of Python can be better supported more quickly. I don't guarantee that this will happen overnight, but I'd like to make a start.