25 Mar, 2008
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!
25 Mar, 2008
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 acquaintaince who refuse to accept my explanation that all London numbers are eight digits long and have the exchange 020.
16 Mar, 2008
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 :)
15 Mar, 2008
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!
15 Mar, 2008
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.