Nicholas “@ntoll” Tollervey has been the London Python Dojo’s parent for all its young life. Once it achieved toddler status, he felt confident enough to start letting other people look after his baby, so over the past few Dojos various other people have run things on the day, always with @ntoll in attendance. Yesterday was the first day on which he felt confident enough not to be there, leaving things in the hands of @tomviner (who could be seen consulting a trusty checklist throughout the evening).

As I re-read, I realise that it looks as though I’m accusing @ntoll of being over-possessive, which I most definitely am not. He’s done — and continues to do — a fantastic job at organising the Dojo and making it happen even when he’s not the evening’s MC. We’re just delighted, as Tom said last night, that he doesn’t feel that he needs to attend it every first Thursday for the rest of his life. (A little secret: the day before this month’s Dojo he was still sending mother-like emails to the rest of the organisers: don’t forget to … remember that … have you …?)

Last night’s Dojo was fun as usual: we were doing the famous Game of Life — probably a text book example of a text book example! Uniquely in my experience, every team had a working version to show after just an hour and a half. The team I was in managed to get something working while @john_chandler and I were still chatting in the background. We fiddled about with it a bit, adding a few preset forms to seed the board etc.

An unexpected visitor was @JohnPinner (of PyConUK fame). He was in London for a meeting and timed things so he could come along for the start of the Dojo, altho’ he had to dash after about an hour to catch his train home. He gave a lightning talk at the beginning outlining various Python-related conferences and training sessions which in the offing. Including this year’s PyConUK, once again in Coventry.

@tomviner’s novelty for this Dojo was the favourite-module question on the sign-up form, which was also used as part of the introduction session. Perhaps unsurprisingly, Kenneth Reitz’s requests module was the clear winner (the only one with more than one vote!). Other unsurprising entries included itertools and collections, but there was a variety of others. I was chatting with John Pinner about the line-up for PyConUK this year, and he pointed out that there’s some mileage for simple talks about a particular module, eg logging or itertools. I’m thinking of proposing such a thing for future Dojos…

There’s also been talk on the python-uk mailing list of a second London-based Dojo, or other Python event, on a Sunday. That might suit some people who can’t make a weekday evening in London but who could manage a weekend. And the more Python events in London the better!

Last night was the first time I’ve actually run the London Dojo. For the two and more years since its inception, Nicholas Tollervey (@ntoll to his Twitter friends & acquaintances) has indefatigably turned up every first Thursday to clear up the Fry-IT offices, order the pizza, buy the beer, put up signs, leave out sticky labels, request free books from O’Reilly and then drum up support, keep everyone happy and actually run the show, finishing off by organising everyone to clear up, move chairs, dump the rubbish outside, and finally catch the last train home to Sticksville, Northants. where his wife and children have long ago fallen asleep over their sheet music, having gone da Capo al Segno one time too many waiting for him to return home.

A few months ago, Nicholas asked for volunteers to help out, and a small group of us got together to share the burden. Since then, Bruce, Jonathan, Tom and finally I have taken a turn at organising. And of course it’s not until you have to do it yourself that you realise how much work is involved… I was fortunate because Gautier (who actually works there) and Nicholas himself were both at Fry-IT for the day and were able to do some of the less proximate preparation, including ordering a dozen pizzas and buying three dozen bottles of beer. I was able to make a small contribution in the shape of a pack of sticky labels.

The Dojo itself was very slightly quieter than usual: just under 20 rather than just under 30. That’s not a bad thing in Fry’s offices which are not huge. There was a bit of an introduce-yourself session (which was made even more primary-school-like by the presence of big sticky labels on everyone’s chest with their names or cognomens). And then we had a lightning talk from Martin who has a sort of cut-down Nagios for app developers. (I hope I haven’t done it an injustice). And then a surprisingly straightforward vote on the evening’s programming challenge which gave us… Boggle. (Word game; 8×8 grid of random letters; form words by moving like a chess king).

Four teams; four solutions, all more or less different. Only one team ended up with a working solution at the end of 90 minutes (and they appeared to be optimising by removing all vertical whitespace; or maybe that was an aesthetic choice - who knows?). Our team had visible activity (which is more than Team 1 managed!) but no solution. It’s up to each team how they want to manage their collaboration. We’d gone for the split-team approach, dividing the problem into its eminently decoupled parts: a mechanism to read in a dictionary of words and provide efficient searchability (using a Trie, in case you’re interested); and a structure to hold the board (a dictionary, keyed on coordinates), generate the letters into the grid, and search for all possible words, relying on the dictionary code to indicate success, failure, partial success, or success with more possibilities.

The tweets were still flying this morning as people tried to tweak their solution (or, indeed, get it to work at all) on the train, on their phone or at home overnight. A friend of mine who’s a C++ coder came along mainly because I’d talked so much about the Dojo. He’s not really into Python - in fact he’s not really a programmer: he does medical image analysis. But he enjoyed the atmosphere and made a few small suggestions before simply sitting back and watching the teams get to work.

Look out for the next Dojo at the beginning of January. It’ll be announced on the python-uk mailing list and we’ll tweet about it when we’ve fixed a date.

UPDATE Dirk’s added a blog post of his own:
http://elazungu.wordpress.com/2011/12/02/solving-boggle-with-python/

But it was worth it. Mendeley have larger offices than our usual host, Fry-IT. And while there were slightly fewer of us than normal (low 20s as opposed to the usual high 20s) it was still great to have a bit of breathing space. Thanks very much to the guys at Mendeley for hosting us (and providing pizza, drinks & snacks).

Jonathan Hartley was making his debut as compere and managed very effectively. Well… fairly effectively. (I shouldn’t laugh: it’s my turn next month). He’d lined up three “lightning” talks to kick off with. First up was Ian — who’d arranged for us to use the place. He explained what Mendeley does (a sort of social network for research students) and how they use Python (mostly as a scripting API) and demo-ed some fairly nifty visualisations and tools which people had built on top of their product. Jonathan himself spoke last to ask for help with a Django concurrency issue. Which he promptly got. In between was Robert Rees who showed-and-told very effectively the recently-added Heroku support for Python. This enlarged into a wider discussion of Heroku itself and of its competitors in the Django/Python world.

Then the Dojo itself. As usual, we had a whiteboard available beforehand for people to propose ideas which were then voted on. The Roman Numeral Calculator remained top of the list of unchosen ideas, but the surprising winner was Robert’s suggestion of an ASCII Art Streetfighter clone. (Chosen only after a second round of voting with a Multiple Transferrable Vote). Once this was settled, it was a simple matter of dividing into teams and hitting the editor.

Or almost. We initially failed to be able to count up to 5 in order to divide into teams. Having finally achieved this intellectual feat, we encountered the opposite problem to the one we normally face at Fry IT. There, the office is so small that you’re squeezing into space. At Mendeley, there’s so much space that you’re wandering around for ages trying to find the best spot. And then you’ve got to find the WiFi (which Ian had considerately explained about). And then you’ve got to manually set your DNS Servers to something (as the DHCP wasn’t handing out DNS). Slightly geekily, the WiFi password is mathematical making it easy to remember but still quite long.

And then, in our case, you had to find the Pygame curses emulation which someone knows exists but can’t quite remember the name of. Having got there (with about 20 minutes left now to do the actual coding) you basically scramble your way through a stunted version of Streetfighter (whatever that is; I have no idea), getting a basic solution on which you layer colour and fonts in the manner of lipstick and pigs :)

Finally, the endgame; and it’s the usual hilarious collection of imaginative approaches, stylishly-designed code, and desperate hackery. We saw: elegant ASCII art; flying bullets; gratuitous use of decorators; and many entertaining attempts to achieve an equilibrium between using classy and best-practice code and actually coming up with a solution within the timeframe!

I don’t know where we’ll be next month, but stay tuned to the python-uk list where stuff is announced.

It looks to be a bit more casually organised than other conferences and I’m very much hoping that the always friendly atmosphere will be even more friendly… See you there, I hope!

The short version is: I’m not mad about the layout; it’s not entirely what I expected from a Cookbook; but I think it does what it does very well.

Since I’m overall positive, I’ll just pick up on the very slight negatives first. In a previous Packt review I commented (adversely) on the style of the layout and so on, and I’m afraid that it hasn’t really changed. Obviously, this is somewhat subjective, but I can’t be the only person who’s subconsciously affected by the font and layout choice. (Bear in mind that I was reading it via PDF which may make a difference). To be clear: it’s not awful; it’s not even bad; it’s just suboptimal.

The other slight negative is hardly a negative at all: that the “recipes” in this cookbook are far broader — in some cases, chapter-length — than I’d expected. Subjective expectation, to be sure. But I was a very little bit surprised.

Ok, that’s the downsides. Now the upsides:

* Nice division of chapters
* The right pacing
* Pretty much one example used throughout
* “Why didn’t you do this?” question sections
* Good re-use or alternative use of previous examples or approaches
* Interesting spread and combination of toolsets

The chapter divisions are: unittest, nose, doctest, BDD, UAT, CI, coverage, load-testing, good habits. In broad terms, each chapter builds on previous ones, but thanks to the reuse of the a simple shopping cart example, repeated in nearly every chapter, you can take a chapter on its own without too much difficulty. In addition, different chapters sometimes offer alternative approaches to the same problem when it makes sense to illustrate one point rather than another. One chapter, for example, walks you through creating a nose plugin to show how to do it; the next chapter introduces you to a ready-made one since the focus of that chapter is not nose plugins.

And that brings me to the variety of toolkits & modules mentioned throughout the text. This is not a book which simply uses stdlib code to perform various tasks (which I had rather thought it might be when I started). It introduces the ideas mentioned in the paragraph above. And puts forward Python modules (such as nose or mock) or external tools (such as Hudson / Jenkins or TeamCity) as best-of-breed or useful tools.

One final point which really put the icing on the cake is the occasional introduction of pull-out sections answering the very question which was occurring to me as a reader: “Why didn’t you use this technique here?” or “How is this different from that?”. Perhaps it’s just me, but I find this smoothes my progress through a book considerably which otherwise would be (mentally) jarred by my wondering “Now why did he do that?”.

I can’t but recommend this book. There’s a sample chapter here if you want to have sniff. As a final note, it’s very slightly unfortunate that the timing of its production precluded the author from picking up on Michael Foord’s magnificent work in producing unittest2 / unittest for 2.7 & 3.2. Perhaps there’s a “missing chapter” opportunity in there for someone…

I sympathise, but for me the simple answer would be: because Python 3 support doesn’t solve a problem I have. It’s one more hurdle to leap over in terms of developing, documenting and testing software. And if you’re still using 2.x for production purposes then you don’t need 3.x. Other users might, but there’s little enough time to scratch one’s own itches let alone scratch other people’s for them.

On the plus side, I’m trying to keep my own modules Python3-friendly, running Python 2.x with the -3 flag, making a few decisions which I know will help 2to3 out (or will remove the need to use it altogether). But at the end of the day, the things I write need to work for the environment I have — which at the moment is 2.7 — and not for the environment I’d like other people to be running.

[UPDATE: Thanks to Mike Driscoll for pointing out how to link to a tweet].

I don’t know about you, but I have sort of one-man sprints on some of my modules when for days on end I take my laptop on trains and squeeze in time at lunch or whenever to refactor or enhance modules. The only trouble is that I’m very (read: too) particular about the quality of the code I release to the public. I want to make a good impression. I want it to have good test coverage. (Or at least some test coverage). I want it to have good docs, with an overview, an API guide, and a cookbook. I want it to have a roadmap so people can see what to expect. (And what not to expect).

But of course all that takes time and energy from the limited pool of time and energy at my disposal. And I have several projects, all competing for that same time and energy, not all of them related to Python or programming at all. Like most developers, I suspect, I’d far rather be writing new code, juicing up existing code, refactoring code for the new generation of language features, breaking code out into nicely layered, suitably decoupled modules. It’s not that I don’t value docs, test, etc. I do. But someone’s got to write them. And that’s me.

Also I don’t want to go public with an underwhelming feature-set. I don’t want people saying, “Oh good… Oh no! Where’s….?” So I go on extending the code forever and never actually releasing. The Perfect is the proverbial enemy of the Good.

The case in point at the moment is the rewrite of my active_directory module (cunningly entitled active_directory2). It’s more or less of a ground-up rewrite with a very similar API but more structure and layering etc. etc. The rewrite’s been on the go for well over a year in bits & pieces. The trouble is that the original module works fine for most of what I want. Very occasionally I need something more sophisticated and I can usually cobble something suitable together for the occasion. So there’s only a low incentive level.

Testing it’s a bit of a ‘mare as I need an test AD rig. Obviously. So, courtesy of the PSF MSDN Subscription — which, it seems to me, was created for just this kind of situation — I’ve installed a VM containing Windows 2003 Small Business Server. This is about the smallest modern server which will host Active Directory. This setup has the slight advantage that it forces me to test AD authentication since, in an inversion of the norm, I’ve already logged onto my laptop before firing up the AD server so it can’t be the authenticating agent for my account.

I’ve got the top two layers working and I’m looking at tests — at the very least, exercise tests: ie those which simply call every function just to make sure it doesn’t completely fall over. Then I’ll probably release it as a work in progress while working on the more sophisticated extra layer which does some transparent transformations to and from Python types based on the schema definition of the AD object and which handles things like memberOf entries in a more Python way.

Watch this space…

One phenomenon I’ve experienced is that I’ll not even have *heard* of some underlying library or web service until someone writes a Python interface to it. Glancing randomly at the current PyPI front page, I see “Python yubico client” which refers to some kind of one-key logon service which I’d never heard of. Then there’s “sunburnt - a Python interface to Solr” which, it happens, I have heard of. And a project which refers to the “Comprehensive Knowledge Archive Network” which, even after I’ve visited the website, I’m still not very clear why I might want to use it. But I’m sure it’s really good for the people who do.

This is great news for two reasons at least: people are using Python for all sorts of things, and not just the big-named everyone-does-that stuff; and there’s an inadvertent advertising effect when they publish their work, which brings a possibly interesting project to the attention of a wider audience.

Which brings me to the main point of this post: from time to time I see a project go past which really grabs the programmer in me, and I just wish I had an excuse to use. Occasionally I actually get to fulfil this wish, but usually I just look wistfully on and check as each new update is released to see if there’s any way I can squeeze it into whatever I am paid to do (or have time to do otherwise).

• Kamaelia - I’ve followed this one since its owner (Michael Sparks) presented it at a London Python meetup some years ago. I love the idea of simple objects and network pipelines between them. (Who wouldn’t?). I recall a thread a few years ago where Michael wondered why more people hadn’t taken it up (and why they’d gone for Twisted instead which seemed so much less intuitive).
• Celery - obviously not unrelated to the previous entry. My interest in lightweight distributed message passing probably goes back to my days using Modula-2, the language I used at University and which led to my discovering Python. (Modula-2 has built-in support for coroutines).
• requests - bit of a newcomer but it it exemplifies one of the things I admire most about Python code: it makes it really easy to do something which is conceptually simple. In this case, making HTTP requests. I think this is a key differentiator when comparing Python to other useful and successful languages: it just doesn’t take much code to get something done. It’s something I try for in my own libraries, and is, sadly, one of the reasons why the built-in logging module gets such a bad press. (In spite of its author’s ready willingness to answer questions, address issues, improve things, and update docs).
• Whoosh - a pure Python search engine. For no very good reason, the idea of doing this in pure Python appeals to me. As it happens I’ve rolled my own search facilities for several small projects. (And who hasn’t?). Unfortunately, the cognitive overhead of replacing those by Whoosh is just too great at the moment to justify the small risk in changing. One day…
• PyMongo (or any other of the several interfaces to MongoDB). As a daytime database developer, I’m as intrigued as the next man by the various schemaless / distributed databases currently going under the “NoSQL” umbrella. I’ve played with CouchDB (very RESTful interface but map-reduce all the way down) and MongoDB (less pure but more practical) and I even toyed with re-implementing our Helpdesk system using one of them, but as ever the risks were too great and there’s no real benefit to the business. (Only to me :) ).

There are loads more; these are just some that occur to me. Others include the kind of popup notifiers inspired by Growl, lkcl’s recently-discussed pyjamas and even some Windows-specific functionality within the pywin32 modules.

If only time and opportunity allowed…

We started with a couple of lightning(ish) talks. Ravi had been on the StartupBus and he and the team had produced the final winner: TripMedi. Ravi explained the way the thing works and various of the challenges involved. He also explained how YCombinator works — something I’d only been vaguely aware of. [On a personal note, I can’t even imagine the kind of person who’d actually want to make use of what TripMedi provides, but I suppose it takes all sorts…] UPDATE: Ravi has just tweeted that the team has made it through to the next stage of YCombinator. Congratulations!

I then gave a presentation on contributing to Python core development and how you could go about it. Thanks to the efforts of Jesse Noller, Doug Hellmann and others, there is now the Python Insider blog, whose intention is to give greater visibility of some of the wider-reaching discussions taking place on python-dev. And the new core-mentorship mailing list is specifically intended to welcome would-be contributors who aren’t too sure how to go about things, or what the ground rules and policies are.

Once all the talking was done, the trouble started :) Nicholas, the indefatigable organiser of the London Python Code Dojo, has been quite keen on promoting XMPP (aka Jabber) to implement some sort of network-ability for our nascent multi-Dojo game engine. For the previous Dojo, his team had produced a simple XMPP Component which implemented a to-do list: the challenge for that Dojo. This time, Nicholas was keen for everyone to have a go with the same thing. He’d put code on Github, added a readme, and recommended the lua-based Prosody server and SleekXMPP for the Python end.

So we broke up into small groups (as they say), fired up git, pip and whatever, and dove in with about 75 minutes to produce something.

About 45 minutes later, most of us were still diving in, trying to get Prosody to listen to anything and failing to get the component talking to Prosody.

At this point, Mr Tollervey very wisely decided that we should cut our losses. Fortunately, John Chandler was willing to go up front and ask for a code review of the code he had produced. Which turned out to consist of two lines, one of which was “import random”. Being social coders, we were more than willing to advise him on the many ways in which he could make this simple and correct code into an over-engineered mess of obfuscation.

Since we’re in the middle of PyWeek, it seemed apt to have a demo from Daniel Pope of the game he’s developing on the theme of “Nine Times”. Impressive as always. (If you haven’t seen it, check out Bamboo Warrior, one of his previous efforts).

As always, we ended with a raffle of name-stickers for an O’Reilly Book and — this time — an additional donation from Mr Tollervery himself. Ironically Jon “I don’t like XMPP” Ribbens got the O’Reilly book on XMPP.

Watch the python-uk mailing list or follow ntoll on Twitter to know when tickets are available for the next Dojo (it usually takes place on the first Thursday of the month).