Moderate Realism

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…)

Not uncommonly, I suspect, Python was introduced here at work in stealth mode: it wasn’t on the list of products starting with “MS” which we genreally use, but it got the job done and the management has been pragmatic enough to accept its use to the extent that it’s now installed on the baseline image for company PCs and laptops.

So what do we do with it? Well, a surprising amount when I start to enumerate it. As is often the case, quite a few of the uses are of the “glue” style: creating an easy bridge between two other pieces of software, one of which is often the operating system. As an example I years ago wrote a (tiny) piece of code to enumerate the installed printers and pipe them out to a file. Our in-house business app calls the Python and picks up the result to display to the user as a pick list. That’s just one example among many others, some of which are so small that I tend to forget that they exist until some bizarre corner case arises which means I have to revisit the code. They just work and go on working.

A by no means exhaustive list of Python Pieces off the top of my head:

* That list of printers
* The startup wrapper for our main business app
* sql2xl — provider of data to the masses (and indirectly responsible for a world of Frankensheets, I’m afraid).
* Sales Boards - our Pygame-driven availability-visualisation app
* reports - a compact module combining simple dialogs and sql2xl
* screengrabber - capture parts of the screen to save to the database
* imageviewer - simple pygame-based image display
* convert images provided by our customers to thumbnails and place them on a replicating database for our handheld scanners
* convert a batch of Word docs to PDF & PCL
* simple manipulation of DXF maps to add our internal site ids
* absolutely loads of occasional AD / filesystem / WMI scripts for the sysadmins
* the internal contacts / portraits webpage
* web-based password reset for our HR system
* web front-end, mail ingest and alerting (a la Roundup, I admit) for our Helpdesk system

.. and a whole slew of other stuff which pretty much exists to demonstrate just how versatile Python is :)