Pythoneering

http://www.jacobian.org/writing/2007/nov/13/book-update/

(Damn, need to wipe that drool off my keyboard…)

After Adrian’s announcement that a Django book was in the pipeline, I just had to place my advance order with Amazon (like many other Djangonauts, I suspect). Since then, news on the book’s progress has been hard to come by. Not any more, though, with the appearance of www.djangobook.com.

This site will allow the Django community to participate in the production of Adrian and Jacob’s book, in much the same way that Bruce Eckel has allowed readers to comment on his material as it is written. Of course, the Django book site is a much more impressive piece of work than Eckel’s system, showing off Adrian and Jacob’s ‘leet web dev skills to the full. It is Django-powered (natch) and distinctively styled, with a neat mechanism for viewing and adding comments and an Atom feed so that we can all keep track of new chapters as they appear. Excellent stuff.

The Django project’s installation of Trac seems to be suffering from an ever-worsening spam problem. I checked the project timeline for 27 October and saw 32 tickets reopened by spammers, compared with 2 legitimate new tickets reporting defects, and 2 changesets. How difficult would it be, I wonder, to prevent this with a captcha-based system of some sort?

Googling suggests that there’s been some discussion of captchas within the Trac project, but that incorporation of such a system into Trac won’t be possible until the 0.11 release. The 0.10 release, however, allows the use of the SpamFilter plugin, which supports regex filtering, IP blacklisting and Akismet. Is Django’s Trac site using this to the full extent possible (or using it at all)?

I suppose the other solution would be to restrict the Trac site to registered users only. Personally, I wouldn’t have a problem with that.

This is exceptionally cool, and a real testament to Python’s flexibility.

It’s that time of the year again, when our final-year students begin their project work. In the run-up to project selection, it was tremendously encouraging to see how many of them were keen on using Python in general, and the Django framework in particular. And it now looks like two or maybe three of my four students will be making significant use of Django. Java doesn’t go unrepresented either, with one student planning on doing interesting things with Eclipse and version control.

Anyway, I hope all of my guys get stuck in and do some good work. Projects that go well can be as rewarding for the supervisor as they are for the student!

Having only recently decided to get a personal Django-based project off the ground, I now find myself with an opportunity to use Django for a project at work. I think that RunLog is going to have to take a backseat while I concentrate on something a little more serious.

For a long while now, I’ve been merely tinkering with Django. I’ve tracked its development closely and with great interest - even contributed some unit tests for template tags - but my use of the framework has been limited to experimentation.

I’ve finally decided to bite the bullet and do something more concrete and useful. I do a lot of running in my spare time and I’m fairly serious about it. By “serious”, I mean that I’m a member of a running club and compete in races every now and then. Runners like myself frequently log the details of their training and racing: where they ran, how far they went, how long it took, the effort involved, etc. I first started doing this on paper years ago, then moved to an Excel spreadsheet with an elaborate set of macros to compute mileage per week or month and sundry other statistics. Of course, it is far more sensible to do this in a database, with a front-end to provide the necessary business logic and user interface.

Hence, we have RunLog: a Django application for logging and analysing training runs and races. A first prototype is nearly finished and, if everything works as expected, I’ll stick it online for others to try. Drop me a line if you are a runner and would be interested in evaluating or contributing to this project.

I’ve recently been thinking about why I like Django, and why I’ve ended up spending time with it rather than with something else like TurboGears. It may be largely accidental, in that I came across Django before I’d heard of TurboGears. In fact, my prior experiences with CherryPy lead me to suspect that I’d have been pretty happy with TurboGears, had I discovered it sooner. But Django snared me first.

So why do I stick with Django for my experimentation with web frameworks? Here, in no particular order, is a list of the things it has that I particularly like:

• A well-designed, easily-navigable, unfussy website, providing access to some excellent tutorials and other documentation
• A simple, compact template language that forces business logic into the view code, where it belongs
• A rich set of generic views that allow useful functionality to be delivered with a minimum of code
• An attractive and highly capable administrative interface to the underlying database, generated for free from the data models

All pretty compelling, as far as I’m concerned. I wouldn’t rule out switching to another framework, but it would have to provide all of the above, and improve on some of it, to tempt me away from Django.

Guido’s recent pronouncement recommending Django as ‘the’ Python Web Framework seems to have got some folk hot under the collar, and prompted a few criticisms of Django. I wonder whether Django’s image might suffer a little at the hands of people envious of the endorsement it appears to have received. I hope not.

Hopefully, people will realise that the comments of one individual, even one so illustrious as the BDFL, aren’t a serious threat to a project with the momentum that TurboGears has. But if Guido’s comments have the effect of dissuading Joe Programmer from writing Yet Another Python Web Framework, and encourage him to help make one of the existing successful frameworks even better, then they will have been well made.