In common, I suppose, with many developers I try to keep track of what’s new and what’s coming up in the technical spheres in which I move. In my case that largely means Python, SQL & Windows although my interests do extend further. I keep a weather eye on things like the Python announce list, the PyPI feed and other sources of updates. When I see something new go past which might be interesting, I might go to its web page, skim the README &c. If it looks interesting or useful enough I might download it and try it out. The same applies to updates to libraries and modules I already use. A new version’s out: have a look to see if it’s offering enough to make it worth upgrading.

But it’s well known that documentation is often the poorest part of the package when it comes to open source software (and it’s not always that much better elsewhere, either). And when it comes to trying to get hold of a whole new module or library, it can be quite daunting knowing where to look, where to start. And for me, that’s where the CHANGELOG comes in. Most open source projects have either a CHANGELOG file or at least access to the change control log entries. Browsing through those can be extremely instructive, both to see what the developers’ (or, more commonly, developer’s) focus has been recently and to give some kind of starting point for investigating the library.

Obviously, if you have a very well-defined goal when you come to a module and / or the documentation’s top-notch then this approach is less useful. But, as a developer myself with my own under-documented modules, I know that I’m more likely to pour useful information into a CHANGELOG entry or a commit message essentially because it’s fresh in my mind and I think conscientiously that I should document it somewhere. Certainly, the source is the ultimate fount of knowledge, but even well-written source doesn’t always illuminate the developer’s intent, while a log entry — especially when coupled with the changeset information — often will.

Oh yes, and the thing which prompted this particular diatribe is that I’ve found the “What’s new in Python…” documents, lovingly written and maintained by Andrew Kuchling, to be fantastic documents. Not just for their stated purpose of indicating what’s coming up in the next release, but also as a bit of a backgrounder to lots and lots of little things in Python which, as a constant Python user since 1.5.2, I still don’t know about or forget. Thanks, Andrew!

Warning: this post will mean nothing to you unless you live or have lived in London. It may — and this is entirely the point — still mean nothing to you even if you do!

It boggles me how many people — including, apparently, professional sign-writers — still think that London is divided into two telephone codes: 0207 and 0208. Having lived through the 01/081/0181/020 debacle, I entirely understand where the misunderstanding comes from. But it’s been nearly ten years. And there are otherwise intelligent people of my acquaintance who refuse to accept my explanation that all London numbers are eight digits long and have the exchange 020.

I work in Camden Town in the north of London, a mecca for youngsters shopping for the more outlandish kinds of outfit, and one of the most difficult places in the known universe to park in. Jamestown Road, just off the Camden High Street, is a popular spot for parking with a good view of the pay-and-display machine. Of course, if you’re entitled to a disabled person’s badge then you or your driver can park without paying (within certain restrictions). Now there’s obviously nothing to prevent someone who’s disabled in some way from being the owner of a fast and expensive sports car. But when you see three or four of them a day parked along the road, proudly sporting their Blue Badge, you stop and wonder…

… and sure enough, there are periodic newspaper reports of a thriving black market in Blue Badges. Obviously, there are greater threats to humanity, but you do wonder whether the veritable swarm of traffic wardens which Camden Borough appears to employ for no better purpose than to maximise their income from parking revenues might not be employed to better effect by standing by Blue Badged cars and waiting with a video camera for the entirely able-bodied driver to show up!

More SQL than Python-related, but in fact the immediate inspiration came from this month’s PyMag, which is a bit database-oriented. In his article on good practice in database design, Brian Jones touches on an issue which I’ve felt many times before. There are, let us say, two kinds of developer: those who are primarily interested in the front-end and for whom a database is merely a convenient back-end store; and those who are primarily interested in the data, and for whom any front-end is merely a means to view that data. Obviously I’m polarising the positions here, but it’s surprising how often you can look at a third-party app and get an idea of which camp its developers belong to.

I style myself a database developer. This doesn’t mean I despise front-ends and prefer to look, Neo-like, at streams of data falling in green down my screen. (Although sometimes…) Rather, it means that I’m much more concerned about the data structures and their interactions at the database level, and keen that the UI do a good service by the data. This may of course reflect my almost complete lack of visual design flair: the best thing you can say about my interfaces is that they are workmanlike and competent, conforming as far as possible to established UI guidelines. They certainly don’t have any kind of panache.

To some extent this also reflects in my slowness to take up the various ORMs on offer, although I have recently started using Elixir for a personal project, and found it very workable. In general, though, I prefer my data raw, not cooked, and the typical examples of ORMs tend to be aimed at people who find data a bit of an embarrassment and want to get it out of the way as quickly as possible :)

Documentation: how we love to read it and how we grumble when it’s not there; but how we hate to write it. Well, not exactly hate; more, can’t get round to start writing it. Those who follow the in-development version of the Python docs will have noticed a number of significant differences, along with a lot of familiar stuff: Same Quality, Great New Taste! A team spearheaded by (and pretty much consisting of) Georg Brandl has undertaken a massive transformation of the Python docs, leaving everything exactly the same, only better.

The new docs are in rst format with special markup added to suit the specifics of the Python documentation. The Sphinx documentation toolset (not to be confused with the Sphinx search engine) written and maintained by Mr Brandl then takes the rst files and renders them as HTML, CHM (the Windows Help File format) or as a web app using werkzeug behind WSGI.

The effect of all this, combined with Python’s move to the Roundup tracker is that the docs are now rather more accessible to the average punter, who can then provide a patch much more easily. In addition, Georg continues to develop Sphinx and to nurture the docs, just as Fred Drake has done for all the years in which they have been in the original LaTeX form.

I’ve always felt that, even though not all of us are able to contribute code patches, pretty much everyone’s able to help with the docs, whether picking up errors or inconsistencies, filling gaps, suggesting new approaches or whatever. My plea is: look through the docs, pick up even tiny typos and report them as bugs, ideally giving a patch against the current Subversion trunk. Georg’s very responsive to issues and is always grateful for patches. In addition, there’s a docs mailing list if there’s some rather wider issue which merits discussion. Join in!

Someone pointed out to me that I hadn’t blogged much recently. I suppose this is the curse of the blogger (or the question, if you prefer): blog early, blog often? or blog only when you’ve got something to say? Well, in a spirit of compromise, here’s a mixed bag.

First of all, I’ve uploaded a few new entries to the Win32 How-do-I? list on my Python pages. One was the direct result of a question on python-win32, while another came out of a fairly FAQ on the Python lists, and one recent thread in particular. The other one has been incubating for ages until could I iron out a couple of bugs, which I did last night.

I have a long-in-progress security module which wraps the win32security functions, trying to make them more Pythonically accessible without losing the degree of control you often need under Windows. Part of the problem is that I’ve tied myself up in knots deciding how to cope with the long sets of constants you need. Numbers? Strings? Sets? Any of the above? My current plan is to get it into a state where I can respectably release it as alpha — pretty much there already — and then stick it up on my site to see what people say. No idea how many people are actually likely to use it, but it does work and it’s been useful for me a couple of times.

I’m hoping there’ll be a Python meetup here in London in March: I’ve missed the last two due to various other commitments, but I mean to get to this one if I possibly can. Meanwhile I’m following PyCon from a distance, mostly via planet.python.org and Flickr.

Trying to keep up a bit of momentum on Win32 How-Do-I entries for my site, I’ve added two more: one illustrates how to iterate over an Outlook/Exchange folder; the other shows how to detach Outlook attachments to the filesystem, replacing them by shortcuts.

After no small hiatus, I have added three new Win32 How-Do-I? entries to the Python section of my site. I have several more in the pipeline but they tend to get pushed down the queue whenever anything else comes up. Suggestions for useful pages are welcome.

In other news, I’ve finally fixed a long-standing bug in WMI which overcached the WMI objects’ method calls meaning that if you looped over a list of WMI objects (say, processes) and attempted to call a method on each one (say, .Terminate) you would end up calling the first object’s method repeatedly… which would give surprising results. A couple of other bugfixes and changes have gone in there as well. I’m now considering where to go next. I’m inclined to do a refactoring, including throwing out 2.1 compatibility but I have an eye to the advance of IronPython and I wonder whether it’s worth it. The latest release is 1.3.2 and you can get it from the Python WMI page or from PyPI.

I’m also trying to fit in an update to the active_directory module which is more geared towards creating & updating objects. The releases up to now have been more or less useful for reading only. The problem is that I don’t have ready admin access to an Active Directory installation so updates are rather sporadic.

Bit of a non-post, but in case anyone’s hoping for immediate help from me, I’m not around for the next week. (And we’ve had no internet connectivity at home since Dec 21st, so I’ve not been around much anyway).

More great news on the Python trunk. Thanks to the indefatigable Christian Heimes, you can now use Microsoft’s VS 2008 Express to build extensions. I built the standard Pyrex primes demo without a problem. This is A Good Thing for two reasons (at least). One: it gives us Windows types a chance who don’t have the resources or even the inclination to invest in the Visual Experience. Two: it demonstrates a vitality in the Windows side of the Python core development, even as IronPython itself gains ground in its own marketplace. (Was that a mixed metaphor? I’m not sure)