reStructuredText files and Crunchy

Crunchy can now handle reStructuredText (.rst) files in the same way it can process plain html ones! This requires the user to have docutils installed - which is normally the case for anyone that writes .rst files.

The test coverage for Crunchy is slowly improving. Currently, 10 modules are mostly covered by doctest-based unit tests, out of approximately 40. Since I make use of .rst files to keep the unit tests, these can now be browsed "pleasantly" using Crunchy itself.

Furthermore ... all the unit tests written so far work under Python 2.4, Python 2.5, and ... Python 3.0a1! This required some tedious rewriting of some parts of the code but the end result is well worth it - if only to really learn about differences between Python 2.5 and Python 3.0.

One thing that I found, which will be no surprise to TDD aficionados, is that code written without testing in mind can be quite tricky to write comprehensive tests for. Add to this the extra complication of making that code run under two incompatible Python versions, and you are on your way to major headaches. It's a good thing I am doing this only for fun!

Launching Python 3.0 program from Crunchy running under Python 2.5

As part of Google's Highly Open Participation contest, Michele Mazzoni completed the task of creating a new option for Crunchy: one can now launch (starting with the next release of Crunchy - 0.9.8.5) a program using a different version of Python than the one used by Crunchy itself. While I had suggested that the alternate Python version could be set via the configuration options for Crunchy (usually accessible from a Python interpreter), Michele had the brilliant idea to add a simple input box where one can specify the path (or 'alias') of the Python version used right on the page where the program is launched from. This makes it extremely easy to change the interpreter version used to launch a user written program.

Michele has prepared a screencast demonstrating this, which should appear on ShowMeDo hopefully soon.

Thank you Michele - and thank you Google!

More results from GHOP

Google's Highly Open Participation (GHOP) contest is attracting a lot of attention from the right people: pre-university students. The PSF is one of ten organizations mentoring students working on Python-related projects. Since I submitted tasks suggestions early on and volunteered to help following a call for volunteers from Titus Brown, Crunchy has benefited from many students contributions. Crunchy's messages have been translated in Estonian, Macedonian, Polish and Italian with, hopefully, more translations to come. Some new unit tests have been added with more to come. There may be a couple of nice surprises coming out soon too :-)

While other projects have also benefited from GHOP's students contributions, there could be more. If you have some good ideas for mini-projects (doable in 3-5 days, at a couple of hours per day with perhaps one full day), your suggestions would most likely be most welcome. Just check out the GHOP Python discussion group. And, if you would like to join the (too small) ranks of Python mentors, please do; we need all the help we can get.

First Crunchy screencast

I finally got around to produce a first Crunchy screencast. Since Crunchy is an interactive program, I thought I should do screencasts that reproduced the interactive feel: that is to say, I would record a live, more or less improvised session. This means that the screen cast is not as polished as it could be - an even has a few minor mistakes in it. Still, I think it gives a good (superficial) overview of what Crunchy is capable of.

What do you think?

First result from GHOP: Crunchy Estonian

By now everyone has probably heard of Google Highly Open Participation contest, and the participation of the PSF. And, initially through serendipity but later with more active involvement, a few Crunchy-related tasks were created including some involving translations. And, just a day after the contest started, a first translation (in Estonian!) has been made for Crunchy by a student named Tanel.

The tasks assigned are usually not very big but they provide nice stepping stones for getting people involved in open source software. Thank you Google for this wonderful idea.

A failed experiment

On a whim, I decided to try a fun experiment: have Crunchy run correctly when invoked either from Python 2.4 or Python 2.5 ... or from Python 3.0! I thought that if I could make it to work, it would be a great tool to go through the 3.0 docs and tutorial, and finding out if there were any mistakes. (I was planning to do this, hoping to help the developing team in my own limited way.)

In the end, I had to give up, as Crunchy uses third-party modules (ElementTree, HTMLTreeBuilder, ElementSoup, BeautifulSoup, etc.) that I could not make compatible with both Python 2.x and 3.0 without essentially rewriting them in two separate modules each. Actually, this was already done for ElementTree (included in the stdlib under a different name) but not for the others.

The main stumbling block was string handling/encoding... This should not be a surprise to anyone who has followed the Py3k development.

Still, I've learned a fair bit from that experiment. One thing that I sort of knew already related to using print statements for debugging purpose. I often sprinkle my code with "if DEBUG: print ...", having multiple print statements appearing. Often I find that I want to have a few debug flags in the same file and think to myself

Shouldn't I replace these print statements by a debug() function with a variable setting the debug level ...

If I would have done something like this, I could have had just a few print statements located in a debug.py module. As it was, with the change in Py3k for print becoming a function, I had to do a lot of changes by hand. Yes, it might have been possible to use the automated 2to3 tool ... but I wanted to maintain compatibility with Python 2.x and, more importantly, get a feel for what was involved in making the code Py3k compatible.

If or when BeautifulSoup, ElementSoup and HTMLBuilder become Py3k compatible, I'll have to give it a try again...

Choosing a CMS ... Will Python make it

This post is not related to programming per se; feel free to skip it ...

"We" are in the process of revamping our web site, and use a CMS. We have just signed off on the first part of the project (new look and wireframe) and are looking at the second (and "final") stage. As we are too small to afford a commercial solution, we are looking at open source CMS. So far, the preferred choice of our director of technology is Alfresco. The choice recommended by our usual technology provider is Joomla! My favourite would likely be Plone - given it is written in Python ;-)

Normally, we would proceed with a public tender - but given that there are few local providers, we may just proceed with the same firm that provided services in phase one. However ... If some of you reading this have work experience in this area, and would be interested in such a project, have a look at our current web site, and give me an informal time/cost estimate of migrating this website to use a [Python based? ;-)] CMS. If we do proceed to tender, you would most likely be included in our list of firms contacted to submit an offer.