Following an interesting-looking link from someone’s blog / tweet / don’t remember led me to the Python section on reddit. Where I was surprised to find a link to my recent print/print() post with some comments. Now, apart from the occasional glance I don’t follow reddit. It looks like an interesting place, but frankly my time is already over-committed and I just know I’ll get drawn into discussing something or helping someone out. So I stay away.

The only drawback to this approach is that people are commenting on a post I made (and which someone else submitted to reddit) without my being aware that the discussing is taking place, and without my being able to engage in that discussion. Which is a shame. But probably for the best :)

We had a blast at the London Python Dojo last night. Food, drink, and location generously provided as ever by Fry-IT (may all their contracts come in on time and under budget!) and a book for the raffle from O’Reilly (may all their titles remain in demand). While the wining and dining (or was that whining and dinning?) was in progress, Nicholas had set up a whiteboard for what-to-do suggestions. When it came to vote, some ideas were thought good but impractical for one evening, and the winner was the original suggestion: Cells.

Well I had misgivings as to whether we could grasp the codebase and get a workable solution in place within an hour and a bit, but it was great. The idea is — within the rules of the game — to pit your agents against the other teams’, trying for a winning strategy combining eating, attacking, moving, and replicating, each of which need, lose or gain energy according to certain rules. The agents can also message others on the same team to communicate, eg, the location of food or enemies. We had four teams, some with agents based on the sample code, others with from-scratch algorithms.

The clear winners were the “white” agents — Team 2 — who’d based their strategy on one of the supplied examples plus an expansion phase which kicked in only once a certain amount of time had passed and involved replicating like mad. On Team 1, we’d gone for a pacifist approach, with some of our agents as “Buddhas”, staying still and eating, the rest “Hungry Ghosts”, eating, moving and replicating. None of them attacked. FWIW, we got wiped out pretty quickly, although that did depend on how far you started from the voracious white team.

The other teams had differing strategies: explorers and eaters; or tribal warfare — which looked hilarious on-screen, as all the yellows suddenly went into warfare mode, sending each other the location of nearby enemies and flocking towards them.

Next Dojo’s in September, but EuroPython’s later this month and I’m sure there’ll be quite a few us there.

There’s a thread over on the Python list which started a week ago as I write and is still running. The OP titled his post the provocative “I strongly dislike Python 3″ but what it really comes down to is “I strongly dislike print()”. Various people have come in on both sides of this well-worn argument.

Now, I don’t really mind futile discussions, and this clearly is one: Python 3 isn’t going to switch back, no matter how many people weigh in on the print-as-statement side. I’m in that camp myself, and when the matter was first up for discussion I had a to-and-fro with Alex Martelli on the subject which I backed away from fairly quickly. I continue to enjoy and benefit from Python regardless; I contribute to its development very slightly and very rarely; and even were I the most prolific contributor on the planet, I don’t believe that would give me any particular right to dictate design decisions of this sort. You take the rough with the smooth.

I think the side of the discussion which irks me the most is from those who are defending the print-as-function decision. Clearly there are cogent and persuasive reasons why print should be / should have been a function. No-one’s pretending that this was a decision taken randomly and for the sake of change. Or even for the sake of a foolish consistency. But if someone’s working practice involves using print a lot — perhaps in the interpreter rather than in a code editor — then the switch to the function version is clearly a burden. It may be more or less of a burden, but it involves having to do something which you didn’t have to do before. Being told that you should have been using logging or pdb or sys.stdout.write — all of which are valid tools to use in the proper place — doesn’t really make your life any easier.

So while Python 3 is now the default interpreter on my shortcut keys and I’m trying to write new code against 3.2, I still find it a pain to overcome the very long habit of, eg, print ad.find_user ().sAMAccountName. Obviously if Python 1.5.2 had had print () as a function originally, I wouldn’t find is so hard now. ;)

(As an aside I did wonder at first whether the American or some other non-UK keyboards had the brackets in some more convenient spot, but it doesn’t appear so…)

Combination of aide-memoire and Python info. If you want to return a datetime object from within a C extension, you need to invoke the PyDateTime_IMPORT macro and you need to do it without brackets and you need to do it from within your module’s import function:

PyMODINIT_FUNC
PyInit_fileutils (void)
{
  PyDateTime_IMPORT;
  return PyModule_Create (&fileutils_module);
}

This is — sort of — expressed in the current docs but because the markup uses the :cfunction: role, Sphinx automatically appends a pair of brackets to the text. Additionally there’s no indication of where to invoke the macro. I tried a couple of places (at the head of the file, somewhere in the code) before discovering that the code would at least compile without it, so I assumed that it wasn’t needed for my simple use of PyDateTime_FromDateAndTime. Until it crashed on me, at which point I went searching and found the answer (thanks, Martin).

I plan to patch the docs, at least to change the markup to use cmacro, possibly to indicate usage once I’ve got some input from more knowledgeable people.

Much fun and laughter at the Dojo last night (helped along, as always, by Fry-IT’s generous sponsorship of location, beer & pizza). Despite the name, this month’s was more of a talks session, picking up threads from previous Dojos and a couple of other random things. Went on a bit long as a result, but good fun nonetheless.

I kicked off with a talk about Pyro, which has recently announced a major version alpha release with versions for Python 2.x and 3.x. We’d discussed the possibility of enhancing our desultory Adventure Game efforts with multiplayerness and I’d volunteered to show how Pyro might be used for the purpose. Of course, the last-minute neatening-up and bugfixes I’d made before leaving the office didn’t make it onto my laptop, leaving me scrambling to correct code with minutes to spare. (Let this be a lesson to you: hg commit && hg push). Although I’d prepared a fairly tight series of examples and didn’t hang around, I still ran for 40 minutes with a few questions thrown in. (Coincidentally, as I sat down again, I had an email from Irmen de Jong, the author of Pyro, asking if I’d tried the new Pyro 4.x on Python 3.x yet. As it happens, I’d intended to do a simple comparison as part of my presentation, but I ran out of time).

Dave Kirby followed from the same angle, with a presentation about Twisted. *His* talk was hampered by laptop-to-projector issues which gave us a green screen, then a red screen, then as we were preparing for a blue screen it went green-red before Gaultier kicked the projector and we went back to white. I certainly came out understanding more about Twisted (which isn’t saying much, admittedly) and I can see why people enthuse about it so much. I’m also aware, from comments on the main Python mailing lists, that the Twisted guys have done a lot of work to file away the rough edges which result from getting low-level cross-platform networking code running.

I think Tom Dunham’s presentation was the best of the night (altho’ I’d had a glass of wine by then, which probably helped). A few dojos ago, one team had used Divmod’s Reverend implementation of a Bayesian classifier as a way to have more flexible parsing / analysis of the user input. It had worked at first, but had soon fallen apart in spite of some ingenious (read: desperate) attempts to “trick” the classifier into giving the desired result. Tom had gone away to investigate how we’d misunderstood the way in which such a classifier works. He came back with a presentation which skipped the maths (fortunately for most of us, I suspect!) and focused on the internals of the classifier, showing how our approach was hopelessly overloading the classification pools to the point where it would classify “the moon is cheese” and “the” in exactly the same way.

Jon Ribbens followed with a demo of his — now quite mature — jon.py web framework, built before almost all the other ones in common use today but still offering remarkable value for (no) money.

In spite of the late hour (gone 10pm before he started) Nicholas Tollervey, our brave organiser, gave a Lightning talk on FluidBD, which answered at least some of the questions we had about it (such as: what is it?), although it left me with the impression that it could be a Brave New World or a Interesting Curiosity.

Next time we’ll probably go back into Dojo mode proper, and with a new project to replace our slightly tired Adventure Game.

Trent Nelson has just posted to python-dev about a Microsoft-sponsored proposal called CoApp. The idea is — as I understand it — to support the packaging of Open Source s/w on the Windows platform. The current situation is quite well outlined on the wiki. It looks like a very interesting initiative and I for one hope that it succeeds.

I find exactly the issues that the author outlines on page: open source s/w is mostly *nix-oriented, naturally, and assumes the development setups which that implies. By and large, Windows ports are either best-endeavour bolt-ons or rely on Cygwin / MingW environments. Python performs rather better here with a maintained VS solution, but even there you have to do a little bit more jiggery-pokery with file locations than I’d like.

I’ve signed up for the CoApp announcments list, so let’s see what happens…

Jesse Noller’s just published an article entitled “Why aren’t you contributing (to Python)?“. It’s trying to work out what the barriers are to someone who comes along with a bug, an improvement or an idea which could contribute to Python in some way. As you might expect it’s generated a fair few comments, the vast majority thoughtfully and candidly expressed. I thought about replying over there, but realised I couldn’t possibly be concise enough :) so I’ll jot some thoughts down over here.

The common complaints — it’s too much of a hurdle to report things; they just lie around anyway without any attention; when they do get looked at there’s just a lot of talk and further demands on my time; it takes ages to format the code correctly — are all familiar. Some could be addressed: you can email a report to bugs@python.org; the tracker accepts OpenID & Google logins; someone more familiar could reformat the code. But some are part of the nature of things: even a straightforward fix which finds a champion among the committers still needs tests and docs and may well need more discussion than the originator had thought about for his particular needs. Someone’s got to do the work.

I like the idea of lieutenants (as long they’re pronounced correctly, of course ;) ). I’d certainly step up to be part of a group around Windows bugs / features etc. There are, let us say, political obstacles even for committers: different people have different ideas of what should go into the stdlib and whether it’s worth introducing a particular change merely for the sake of consistency and tidiness, and so on. You can’t just commit-and-run. No surprise for anyone who’s worked on a coding project of any size.

My particular area, of course, is Windows and I’d like to consider the additional barrier to contribution for Windows users of Python. I imagine (always worth imagining in the absence of any credible data) that Windows users, even developers, are less likely to have Visual Studio (or Mingw or cygwin) installed. And even less likely to be using Subversion or Mercurial. Let alone the secondary toolsets needed to do a full rebuild of Python. What this means in practice is that, if a user says: here’s a bug; and I reply: here’s a fix, does it work? they’re less likely to be able to patch the code (or pull the update) and rebuild and test. This doesn’t stop me or someone else testing, but it does disengage the OP from the problem he’s reported. In addition, if he’s a Windows user he’s probably hoping for the next MSI to become available. Which won’t be for a while.

All this is imaginary. I’ve seen no reports of Windows users crying themselves to sleep because they couldn’t reinstall a patched version of Python which fixes a problem. But what is real is that Windows developers are very slightly further removed from the Python development process by the difference in development setup.

So that’s my challenge: to try to improve matters within Python development so that it’s at least as easy for Windows users to get started, to report and test problems, to help to fix things. What will this involve? I don’t know. Maybe returning to automated overnight MSI builds. Maybe streamlining the download / setup / build process on Windows. Maybe getting my act together and documenting things better. Maybe putting a bundle together which makes things easier, as sort of DIY Python Starter Pack. I’ve got the motivation; all I need is the time.

I’ve been involved with Python for at least 11 years, ever since I first used 1.5.2 on Windows 9x. (I recently had occasion to use 1.5.2 on some random webserver and was amazed at how many things I couldn’t do). I don’t know exactly, but I must have started answering questions on the python and python-win32 mailing lists a couple of years later, somewhere around the beginning of 2002. At about the same time I started developing win32-related modules and putting them in places like the Vaults of Parnassus (remember?) before PyPI and before I had my own domain. Over the years I’ve added stuff to my timgolden.me.uk website including a set of How-do-I? pages for win32 questions, often prompted by a question on the mailing lists. The most significant of the modules I maintain has undoubtedly been the WMI module, although the active directory and winshell modules both receive some attention. From time to time, although it’s never really been my main focus, I’ve delved into python-dev and contributed doc and small code patches mostly although not always against Windows. (In fact, my entry in the ACKS file is due to a trivial platform-neutral C-code fix to the multiprocessing code).

If I have a focus, it’s really to ensure that Windows is not a second-class citizen in the Python world. Obviously, Python itself has been running perfectly well on Windows for much longer than I’ve been around but, anecdotally, the easy majority of Python users and developers are Unix people — traditionally Linux, but more recently Mac OS X. So my self-appointed task is to help out wherever possible on Windows: helping newcomers to translate their Windows idioms into Python; making sure that Python does build and can be tested on Windows and that Unix assumptions aren’t preventing code from working; looking for ways to help the stdlib serve better the needs of Windows users; and providing answers and code on mailing lists and my own website to help Python users under Windows.

In the course of this week, I’ve been notified that I’ve been elected as a member of the PSF in this year’s tranche of nominations, and that I’ve been given commit privileges on the Python repository. Both of these, while meaning relatively little to my non-programmer friends, I recognise as reflecting the community’s acknowledgement of my contribution to the language and its trust in my ability to do so. For which I thank the community, and in particular the indefatigable Michael “Fuzzyman” Foord who nominated me for both these privileges, and those members of the development community who were good enough to second his proposals. Meanwhile, I took my courage in both hands and proposed to the head of IT here at work that we repurpose a decommissioned Windows server as a public-facing Python buildbot. Which he agreed to do. He also agreed to part-fund my visit to EuroPython this year. Both of these agreements surprised me not a little, since there’s not much money around and I was essentially putting forward a case based on altruism rather than ROI. Although my boss is a good guy, he’s a commercial manager and has to justify whatever effort and money his team expends.

All I have to do now is to book my EuroPython ticket and accommodation and to submit a talk proposal before the deadline at the end of the week. I only wish there were more time: I have several python-related and several non-python-related projects on the go both at work and at home and there’s never enough time to get everything done :)

Thanks to sterling work by Klaas “le dahut” Tjebbes on the python-win32 list, we now have a how-do-I? example on how to keep track of session events: logon/logoff, screensaver cut-in/cut-out and shell startup: http://timgolden.me.uk/python/win32_how_do_i/track-session-events.html

Just saw a tweet from Rene saying that he’d enjoyed last night’s Dojo at Fry-IT. I did, too, and for much the same reasons: the small group format makes for a more engaged, friendlier evening. We were carrying on with our not-so-spectacular text adventure game built in previous weeks. Altho’ there had been discussion about different groups working on separate pieces which would then come together, I think our eventual choice for all groups to work on the same thing was the right one. As Nicholas — Dojo organiser and former teacher :) — pointed out (correctly): if you’ve all been working on the same piece of code and the same structures, it’s much easier to follow the show-and-tell at the end.

In the spirit of previous Dojos, which had been very much led by TDD-aware people, I’d got all test-y in our group and we spent way more time in generating meaningful tests than launching into functional code. (As well as reworking the crufty parser which everyone had to cope with). As far as I can tell, *none* of the other groups were testing. Just goes to show… testing really does slow you down for no nett gain ;)

It was definitely interesting to see the different styles & approaches adopted by the different groups. As well as their attitude to the source material: most were “respectful” of the descriptions and objects supplied (by Bruce & John) but others simply hacked them about to suit their requirements. And one off-the-wall group simply made up their own thing, generating random monsters doing random things. As far as I could tell.

Although this format worked well, I think varying from time to time is good — as we have been doing — not least because different approaches suit different people and we want people to keep coming! Thanks as always to Nicholas and Fry-IT for organising / hosting / feeding. Pictures are up here. (Apparently that site’s Django driven, in case it makes you any more likely to click on the link…)