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.

pyglet and pygame: which one?

Pygame is great. Pete Shinners has done some fantastic work in creating it. I have played a bit with it in the past and was planning to learn to use it better, and probably write some Crunchy-based tutorials for it. Unfortunately, this will not happen. Since I moved from a PC to a Mac, and installed Python 2.5, I can not use Pygame, as there is no ready-made version for my setup. Yes, I imagine I could find out how to compile it from the source ... but there is an easier alternative: pyglet. pyglet is a pure python library, with no external dependency. I downloaded it, tried it ... and it just worked. Not only that, but when Python 2.6 will come out, I know it will still work.

I do realise that pyglet is just in alpha stage ... but it's a very impressive alpha. It is not as fully featured as Pygame is ... but it works for me, thanks to Alex Holkner.

If you're currently using pygame, there's probably not any reason to switch. But if, like me, you find that you can not use pygame with your current setup, check out pyglet. You might be pleasantly surprised.