Of the comments made to my previous posts, only one outright dismissed PEP8; several spoke neutrally, more or less echoing the sentiments I’d expressed; but the majority which expressed a clear opinion made it strongly advisable, not to say mandatory, to follow PEP8 for one’s own (published) work.

So I’ve decided to switch to near-PEP8 style. (Note that pretty much everyone and every project varies a little, most commonly on the line length issue). The two key points which seemed — startlingly, from my perspective — to bother people the most were the two-space indents and the space-before-brackets. If you cared to peruse my winshell & active_directory github repos, you’ll note that those are now in line with PEP8. Others will follow as and when.

You’re probably not surprised to hear me say that, having made the switch, I can’t understand how anyone can prefer the PEP8 style. If I’ve switched, it’s not because I’ve had a sudden aesthetic revelation which makes me wonder why I wasn’t using 4-space indents all along. Quite the reverse: for the life of me I can’t see why anyone would prefer it. Rather, it’s because I recognise the value of a commonly-held standard within a community. And because, when I weighed it up, there was no reason — beyond my own preferences — not to switch.

I’ve tweaked my SciTE options and added the PEP8 module to my test scripts, turning off certain of the checks and allowing for slightly longer lines. Let’s see what I feel about this in a month or so’s time.

First of all, it seems that you’ve got me coming and going: on the one hand, I’m unreasonable to expect people to adopt my project’s style when contributing to it; but on the other I’m unreasonable if I expect to program the same way in every environment. Let me say again what I said in the previous post: if I contribute to, say, core Python, then I *do* expect to have to change my style to match the project guidelines. Likewise, if I contribute to Pyro — a fairly well-known Python project — then I use camelCase method names, because that’s what its maintainer uses. I don’t find that so very difficult and I doubt it anyone else does either. (Of course my “anyone else does” here is as anecdotal as the generalisations in Luke’s comments and can be treated the same way).

Luke’s basic point seems to be that all Python code *should* look the same, regardless of any other consideration, and that to do otherwise is not to be a team player, to indicate that you don’t care, and to leave open the suspicion that your code is of as poor quality as… well, your PEP8-ness. And I find that position far beyond what I consider reasonable. If that leaves me turning people away at the door then please write and tell me. Perhaps I’m being a single-minded curmudgeon on this issue, but I am honestly bemused at the idea that *all* Python code should follow what is, basically, one person’s preferences.

In short, I would be genuinely interested to hear from other people if they think that publishing Python code which follows a consistent style but which is not PEP8-compliant is that much of an issue. For them, for would-be contributors, or for the image of Python.

Since I’ve written pretty much the same answer whenever this has been raised, I thought I might as well write it here and then point people towards it.

PEP 8 is the Python project’s code style guideline. I quote from the opening paragraph: “This document gives coding conventions for the Python code comprising the standard library in the main Python distribution.”. It is not a guideline for every piece of Python code ever written by anyone. On the odd occasion that I contribute code to the Python core I naturally ensure that my code complies with PEPs 7 & 8 for C & Python code respectively.

I’ve been using the format described above for well over 25 years of coding on different platforms & languages. Along with other aspects, it constitutes my personal “house style”. If anyone wished to contribute to any of my projects I would ask them to follow the same guidelines (or at least, not to complain when I reformatted their code to match my own).

FWIW I find the spam(”foo”) style cramped; no doubt some people find my spam (”foo”) style too loose. So be it. I’m genuinely astonished when people advocate 8-space indents (and I’d be a bit startled by 1-space indents). I find 4 spaces push the relevant code too far away too easily so I use 2 spaces. Barring manifest absurdities, such things are largely subjective.

So now you know: if you see code examples of mine, or are perusing my source code, be prepared for (gasp) non-PEP8 compliance!

• Iterate over items in the recycle bin
• Determine what versions of a file there are in the recycle bin
• Undelete the latest or a specific version of a file
• Empty all recycle bins

You could already delete to the Recycle Bin (via delete_file). Now you can undelete as well!

• pip install winshell
• github: http://github.com/tjguk/winshell
• PyPI: http://pypi.python.org/pypi/winshell
• readthedocs.org: http://readthedocs.org/docs/winshell/

Many thanks to Steve Reiss who took the trouble to let me know it was failing to install

Spurred on by this, I got my act together and shifted a bunch of my code over to github where it is a little more public and where it’s easier for others to contribute. I’ve also made moves to incorporate the changes & patches supplied. At the same time I’ve done a bit of tidying up around the projects and have made use of the wonderful readthedocs.org.

There’s still work to do, but now winshell — one of those tiny helps-you-a-bit modules I wrote eight years ago and which remains basically unchanged — has just seen a 0.4.1 release which has docs and tests and which runs against everything between Python 2.4 and 3.2 (and possibly more besides). The code is hosted at github, the docs are hosted at readthedocs.org and it’s available on PyPI and pip-installable. Thanks to Steve Peck and Roman Luks for patches & suggestions.

My software development tends to go in bursts when the available time, energy & motivation coincide, so lets hope that I can keep this particular ball rolling. My active_directory module is also available on github and has a py3k branch kindly supplied by Ken Gillett. The complication there is that it’s (naturally) against the last released version, which is a few versions behind my private version. If you’re interested, you can fetch it from the py3k branch. My aim is to re-apply the coresponding diffs from the main branch and then look at merging or splitting or something.

I mean to write an entry on the requirement tensions between github, PyPI, pip and the various recommended practices, especially with respect to the README files, but that’ll have to wait for another moment.

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.