Stackless Python release backlog
Quite a lot of work is required to bring Stackless Python completely up to date. In the past, I followed the Python-dev mailing list and when upcoming releases were discussed, I found time to synchronise a matching Stackless Python release. But being disillusioned about the direction Python is headed combined with forgetting to check it out on a regular basis, I have unfortunately fallen behind with matching releases of older versions of Python.
This is the current list of outstanding release related tasks:
| Python 3.0.1 | Merge, bug fix, release | Visual Studio 2008 |
| Python 3.0.0 | Re-release | Visual Studio 2008 |
| Python 2.6.1 | Re-release | Visual Studio 2008 |
| Python 2.5.4 | Merge, release | Visual Studio 2003 |
| Python 2.5.3 | Merge, release | Visual Studio 2003 |
| Python 2.4.5 | Merge, release | Visual Studio 2003 |
Merging and Compilation
Merging is not a big deal these days. Most of the problems in the past were merging mistakes on my part and when the bugs were located, going back to the source code revealed what I had done wrong. The other big merging obstacle in the past was the merge from 2.3 to 2.4, this was significantly more work than any merging effort since, including what 3.0 involved.
Where the effort lies now is in the compilation. To some degree the process of compiling the Python dependencies, but mostly the unreliability of the Microsoft development tools.
Before Windows installers were provided for Stackless, the standard release process for Windows binaries was to compile the DLLs, archive them and upload the archive to the web site. It was a pretty straightforward process, Christian Tismer had even written a script to do it all. But when providing a Windows installer became part of the release process, this mean that all the dependencies of Python needed to be compiled so that they could be packaged by the installation process. This is still a lot of work, but it used to be more before the source code for the correct versions of the dependencies were checked into the Python SVN repository, and scripts were provided to automate part of the building process.
The most reliable Microsoft development tool I have installed, is the free VS.NET 2003 Toolkit which only contains a non-optimising compiler. Due to compatibility reasons, the DLLs for versions of Python up to and including 2.5 are required to be compiled with VS.NET 2003. My toolkit install will, following the steps documented on the linked wiki page, compile binaries which pass the Python and Stackless unit tests, and also build a working installer. The toolkit is a little cumbersome to install and configure with all its own dependencies, but after that process has been completed once, it doesn't need to be repeated.
Visual Studio 2008 is the compiler used for Python 2.6 and 3.0. This I have a full installation of both at home, and at work. The installation at home will not compile binaries that pass the Python unit tests reliably, but it will build a working installer. The installation at work will compile binaries that pass the Python unit tests reliably, but will not build a working installer. I do not own this however, and have a work license covering the home install, so it is a little cumbersome to reinstall it. And there's also the concern that if I reinstall it, things will be even more broken.
So for now, I will merge and build an installer for 2.6 and 3.0 at home. And build the binaries which get distributed in the installer at work. Not an ideal solution, but it is going to have to do.
Priorities
Python 3.0.1 is the highest priority. The older versions of Python before 2.6 are not commonly used, and the requests for the releases which do not have existing Stackless versions already, are very rare. Making a priority of the latest releases helps make it clear that Stackless is still maintained and has not stagnated. While Python 2.3 was the latest version, there was a long period when no-one had the time to keep Stackless up to date, and this made it look abandoned and was a source of frustration to existing users. The older releases are a bonus if I have the spare time to do them.
Edit: Linked to the 3.0.1 merge post.
Hi Richard.
ReplyDeleteWhy are you disillusioned with the direction Python is heading, and what direction do you think it is heading?
Hi Simon,
ReplyDeleteSomething can't of course be all things to all people, and while Python as a language is improving and changing in certain directions, these are not directions are often not appreciated as much by myself as those who participate in them. As to be expected, given I am doing none of the work, nor am I contributing in any direct way.
During the period I was subscribed to the python-dev mailing list, the impression I got was that if someone was willing to do the work and Guido bought into whatever it was being sold, then whatever it was would get into the language. It seemed a raft of things that I saw no benefit in were making it in.
If I pick the one feature that comes to mind first, it would be generator coroutines. To use these as a primitive in a framework inherently adds boilerplate and complication to a developer's code. The ability to switch properly, as in Stackless, greenlets or any similar solution, allows a developer to write more straightforward code. Just because you can extend functionality to handle something in limited way, doesn't mean you should.
There are a number of other things which have been added to the language, and changed made which to me seem arbitrarily decided, but I need to go learn some more C# so have to cut this short :-)