Moderate Realism

From time to time, the idea of a standard Python “Enum” object is raised on the Python lists. You know the kind of thing: a lightweight means of mapping numbers to labels so you can do set_colour(Colours.red) without having a long module of manifest constants or magic numbers lying around all over your codebase.

It all sounds very straightforward, and Barry Warsaw had an existing module which seemed like a fairly good starting point, so PEP 435 was started and it all looked like it was just a formality.

Now, literally *hundreds* of mailing list posts and endless, endless threads later, GvR has just pronounced his approval of the PEP and it’s good to go.

If you — like me — thought “this one won’t be controversial”, then just point your search engine of choice at mail.python.org/pipermail/python-dev and look for “enum” or “435″, or just look at the archive for May alone (which only represents the final few days of details being thrashed out) to realise just how much discussion and work is involved in what appears to be quite a simple thing.

Of course, part of the problem is precisely the fact that the idea is so simple. I’m sure most people have rolled their own version of something like this. I know I have. You can get up and running with a simple “bunch” class, possibly throw in a few convenience methods to map values to names and then just get on with life. But when something’s got to go into the stdlib then it all becomes a lot more difficult, because everyone has slightly (or very) different needs; and everyone has slightly (or very) different ideas about what constitutes the most convenient interface.

And there’s always the danger of the “bikeshed” effect. If a PEP is proposing something perhaps quite fundamental but outside most people’s experience, then only people with sufficient interest and knowledge are likely to contribute. (Or argue). But an enum: everyone’s done that, and everyone’s got an interest, and an idea about how it should be done.

But, bikesheds aside, I’m glad that the Python community is prepared to refine its ideas to get the best possible solution into the standard library. As a developer, one naturally feels that one’s own ideas and needs represent everyone else’s. It’s only when you expose your ideas to the sometimes harsh winds of the community critique that you discover just how many different angles there are to something you thought was simple.

Thankfully, we have a BDFL (or, sometimes, a PEP Czar) to make the final decision. And, ultimately, that means that some people won’t see their needs being served in the way they want. But I think that that’s far preferable to a design-by-committee solution which tries to please everybody and ends up being cluttered.

Yesterday was the March Python Dojo, hosted as usual by the ever-generous Fry-IT, with a book donated by O’Reilly. We started with a couple of not-so lightning talks from Tom Viner — talking about his team’s solution for last month’s puzzle — and Nicholas Tollervey — talking about bittorrent. An artfully-worded late question had @ntoll on his soapbox for a while on the subject of copyright and payment to artists, until someone spoiled it by suggesting that maybe we ought to write some code in Python!

After the usual, only slightly convoluted, voting experience, we decided to pick up one of last month’s runner-up challenges: creating a compression-decompression algorithm. Naturally most people started from some kind of frequency table, replacing the most common items with the smallest replacement. The approaches ranged from a hybrid Huffman-UTF8 encoding to an attempt to replace common words by a $n placeholder, where the n would increase as the word became less common. The winner for the most optimistic approach was a lossy algorithm which dropped every other word on compression, replacing it on decompression by the most likely from a lookup table. Tested against a corpus of Shakespeare’s works it produced some quite readable poetry.

As an aside, I can assert after a wide-ranging survey that (a) the preferred editor background is dark (black or dark-grey); and (b) in spite of all the tech at their fingertips, programmers still reach for pen and paper when they need to work something out!

(No, this isn’t one of those New Year memes; it’s just a bit of a verbal ramble).

I wanted to get an app up-and-running on WebFaction. And, for reasons not necessarily entirely connected with reality and hard requirements, I decided to go for Python3. WF offers CherryPy 3.2 against Python 3.1 but — again, for no very good reason — I decided I wanted the very latest.

So: download cherrypy.latest.tgz and python.latest.tgz. Dum de dum, configure –prefix=$HOME && make && make install. Bit of fiddling about with WF’s cherrypy setup and… we have a problem. The cherrypy engine is, for some reason of its own, using threading._Timer rather than threading.Timer and it’s not there any more in Python 3.3.

Investigation shows that this was fixed in cherrypy a few months ago. Meanwhile things will probably go ok with Python 3.2. What to do? I decided on backtracking on Python (truth be told, I hadn’t checked the cherrypy logs at this point). Download python.32.tgz. Dum de dum… and… error with _posixsubprocess. Looks like it’s fixed in the 3.2 branch but not yet released.

I’m now in the situation where I’ll either have to use a hg checkout of cherrypy or an hg checkout of Python. Or both.

Lest this be seen as a dig at either the cherrypy or the Python guys, it’s certainly not. I’m grateful to them both for the work they’ve done and for the open source infrastructure they use which gives me the information and options I’ve outlined above. I could most certainly backtrack a couple of published versions of either perfectly well for my own needs.

It’s more of an endorsement of what open source offers you if you want (and I haven’t even talked about the fact that I could fork cherrypy or Python if I needed and still maintain a version in sync with the canonical one for my own use on WF).

All I need to do now is clone hg.python.org/cpython, config & make and I’m away.

(This is because I use mercurial rarely enough and commit to Python even more rarely; so I always forget what incantations I used last time…)

hg clone http://hg.python.org/cpython hg.python.org
hg clone hg.python.org issue1234
cd issue1234

hg up 3.3
hg import –no-commit http://…/fixedit.patch
# Do whatever
hg commit -m “… (Patch by …)”

hg up default
hg import –no-commit http://…/fixedit.patch
# Do whatever
hg commit -m “… (Patch by …)”

hg push ssh://hg@hg.python.org/cpython

Well that was fun!

Four days of community-oriented Python. Talks, open spaces, sprints, teachers, Dojos, tubas… PyConUK 2012 had it all.

I won’t retail it all. You can look at the schedule or the videos for yourselves. A few things, though, merit a special mention.

First, the organisers and the venue both managed extremely well. It wasn’t without a few very slight issues, but the venue staff were professional and helpful and the Python West Midlands organisers made sure everything went to plan (adjusting the plan, if necessary!).

Second, the education track. This was a new venture as was fronted by Nicholas Tollervey, himself a former teacher and the prime mover of the London Python Dojo. (Note to self: really must do something about a ldnpydojo website…). We had ICT and other teachers who had a tutorial on the Saturday as an introduction to Python and a sprint on the Sunday with groups of developers to see how to translate technical know-how into practical education. I think most of them also joined the Saturday afternoon Dojo. The most enthusiastic was “Miss P” who also participated in the PyConUK panel.

Then we had Alex Bradbury from the RaspberryPi foundation. He gave a keynote speech on the Saturday and led the very popular RPi sprint on Monday. He’s very enthusiastic about Python and the RPi and education and there was a lot of cross-discussion throughout the conference on those themes.

Finally among many lightning talks — ably compered, as always, by Lightning Talk Man himself — the standout was a performance on two tubas, playing the Sousa march which will be familiar to any Monty Python fan. I’m hoping someone has a picture of the performance which I can link to: the video doesn’t seem to be up yet.

A last shout-out to Tim, the video man, who stood patiently at the back of the main hall throughout the conference, recording every talk and panel, streaming it live and uploading very quickly with your slides synchronised in.