If you haven’t already seen Python Grimoire, go there now and bookmark it. It rules!

As a side note, I guess it’s vocabulary week at Import This. Yesterday was pons asinorum, and today’s word is grimoire:

A grimoire is a book of magical knowledge written between the late-medieval period and the 18th century. Such books contain astrological correspondences, lists of angels and demons, directions on casting charms and spells, on mixing medicines, summoning unearthly entities, and making talismans.

In this case, the usage implies a cookbook style approach to Python. Another example of a tech grimoire would be the Debian Grimoire.

I just found the article called Why Python? written by the ever opinionated Eric Raymond. The article itself is old (circa 2000), but he brings up a few points that are still valid when discussing Python.

Quoth ESR:

Of course, this brought me face to face once again with Python’s pons asinorum, the significance of whitespace. This time, however, I charged ahead and roughed out some code for a handful of sample GUI elements. Oddly enough, Python’s use of whitespace stopped feeling unnatural after about twenty minutes. I just indented code, pretty much as I would have done in a C program anyway, and it worked.

By far, the biggest complaint I hear from people who have never tried Python is that “significant whitespace is lame.” With that single complaint, they vow to never even try the language. Admittedly, I thought it sounded a little odd as well when I first heard about it. But I would agree with ESR, that after a day of writing some code I didn’t even notice I was indenting… it just became natural. Now, when I try to go back to PHP or another language, the brackets and such all seem redundant.

None of this is, of course, new or exciting to experienced Pythonistas. But his use of the phrase pons asinorum (see also: Bartleby) seemed to really sum it up nicely.

There’s a good post over at Groovie talking about Python web framework niches.

The concept I want to focus on is that people create these new frameworks because they make their task easier than any of the other frameworks already out there. While they might pick up features from other frameworks, most of them aren’t aspiring to be “Python on Rails”.

Specifically, he talks about TurboGears and Django. Check it out.

Scott Yang took a look at both TurboGears and Django, and decided to go with Django. He talks about his reasons for picking up Django, but this section in particular stood out to me:

However, at this stage the only show stopper for TurboGears is its dependency on setuptools, which is not trivial to install on shared web hosts without terribly looking hacks.

On the other hand, Django works well without setuptools, and there’s even a how to for DreamHost. Documentation is considerably better than TurboGears (though you still need to look into the source code to work out the magic). It is also easy to integrate Kid and MochiKit into a Django deployment.

Once again it looks like a major deciding factor in choosing a web framework was not which system had the better code, better features, or most boxes in Web2.0 Bingo. It comes down quality of documentation and being absurdly easy to install and use. The devs on both teams would be wise to take heed.

I’ve mentioned this before: here and here.

Update: Please see Scott’s comments below for some clarification.

It was only a matter of time until someone put together a short screencast demonstrating how to use Django. It looks like Tom Dyson is the first with a seven minute narrated video:

It’s not intended as a tutorial - aspects of Django’s syntax are likely to change before its forthcoming 1.0 release, and the project website already provides excellent documentation - but as an introduction to some of the basic functionality.

It’s encoded in H.264, so you’ll probably want to use VLC (now with GUI goodness!) to view it. Tom’s really done a nice job putting it together, and I recommend watching it.

That said, I think it is imperative that the Django team put together a quality screencast showing how easy it is to use their framework as soon as practicable. I think I read somewhere (#django perhaps?) that Adrian wants to wait until the API is frozen for the 1.0 release before doing an “official” screencast. I think that makes perfect sense, but only as long as the screencast really is made available at the same time 1.0 is released to the masses.

It is the nature of web frameworks that they are intended to make the job of web developers easier. Therefore the framework that will be adopted the most will not necessarily be the one with the best code and fanciest features. Rather, it will be the one with the best documentation, best demos/screencasts, and is the easiest for a dev to pick up and run with. The objective should be to get people installing Django and trying it, which will, in turn, build a strong base of people wanting to improve it. Worse is better.

This topic seems to keep popping up; this time from Plumbing Life’s Depths. Quoth Mike:

Which is the problem. Python just makes complex tasks a little too easy… it’s too easy to code new things when something’s wrong with an existing module. Or maybe it’s just that one shouldn’t code with a “I’ve only got a few days to work here, can’t afford to wait for other people” feeling.

In this case he is talking about building his own module rather than using the Twisted framework.

Sounds similar to what Titus Brown was saying in regards to the proliferation of Python web frameworks.

No easy conclusions. Just pointing it out.

Quoth Adrian:

We’ve changed the default session cookie name. Instead of “hotclub”, it’s now “sessionid”. Intended as a reference to the Hot Club of France (one of Django Reinhardt’s bands), “hotclub” had been misinterpreted by some people as having some sort of porn-site meaning.

Oh, well. Wit and obscure references only go so far.

Heh.

For those of you who are not well versed in Belgian Gypsy jazz musicians of the 1950s, Wikipedia has the scoop on Django Reinhardt of Hot Club fame.

Saw a link to pylibpcap on wak tek with some quick usage notes. Looked easy so I loaded it to try it out.

For some reason however, the 0.4 version in portage didn’t work for me. It failed with the following error:

metis $ ./sniff.py eth0 foo Traceback (most recent call last): File "./sniff.py", line 68, in ? p = pcap.pcapObject() File "/usr/lib/python2.4/site-packages/pcap.py", line 35, in __init__ self.setfilter.__setattr__('__doc__',\ pcapc.pcapObject_setfilter.__doc__) TypeError: attribute '__doc__' of 'instancemethod' objects is not writable

Upgrading to the masked 0.5.1 version seemed to fix the problem. No idea why.

Paul Bissex was able to create a rudimentary wiki in just a few lines of actual Python code by using the Django web framework:

I wrote about 60 lines of Python code in total. There are much smaller wiki engines, of course, but given the flexibility and expandability offered by Django I think that’s pretty good.

He describes the process as being “absurdly easy.” And if I were a Django developer, I’d consider that to be the nicest thing someone could say about my software.

I’m starting to get the hang of regular expressions, and understanding the power of “import re” in Python, so this might come in handy:

Kodos is a Python GUI utility for creating, testing and debugging regular expressions for the Python programming language. Kodos should aid any developer to efficiently and effortlessly develop regular expressions in Python. Since Python’s implementation of regular expressions is based on the PCRE standard, Kodos should benefit developers in other programming languages that also adhere to the PCRE standard.

It was written by Phil Schwartz.