Schneier on fighting terror with anti-terror

Probably one of the best articles you’ll see with a succinct message about how we’re doing all of the wrong things in the face of a terrorist threat:
Schneier on Security: What the Terrorists Want

Another thought experiment: Imagine for a moment that the British government arrested the 23 suspects without fanfare. Imagine that the TSA and its European counterparts didn’t engage in pointless airline-security measures like banning liquids. And imagine that the press didn’t write about it endlessly, and that the politicians didn’t use the event to remind us all how scared we should be. If we’d reacted that way, then the terrorists would have truly failed.

In praise of the Django people

As open source projects, TurboGears and Django have their differences. We compete for many of the same users (though there are some things that may be easier in one or the other).  That said, I must say that the Python-web people that I’ve interacted with have been great. Jacob Kaplan-Moss posted his own take on Guido’s Pronouncement, even linking to my post on the subject. Thanks, Jacob!

Between PyCon and EuroPython, I got to spend time with a whole bunch of Python-web people (some of whom I saw in both places: Simon Willison, Jim Fulton, Philip von Weitershausen). It’s really a great combination of competition and cooperation, and I think we’re all the better for it.

Cheers to Adrian Holovaty on the announcement that Django’s going to include optional integration of SQLAlchemy. It’s a good benefit for Django users, and I think all of us that use SQLAlchemy will benefit from the additional users of the project.

Summer of Code Goodies Arriving

Though we still have more than a month of good weather to look forward to here in Michigan, the thought of summer ending and heading into another long winter isn’t pleasant. On the plus side, the end of summer brings the results of Google’s Summer of Code.

The one that I’ve been most looking forward to is Migrate, assistance for SQLAlchemy database schema migration. I just spotted Evan’s 0.2.0 release on the Cheeseshop. Looks good, but it’s a shame that sqlite is left out of some of the goodies.

I’ve also been keeping an eye on Ryan Forsythe’s PyCells project. Cells is one of these libraries that gives you a different way to think about how your code is setup. It’s a sort of event-driven system where changing one value will automatically cause dependent values to recalculate, much like a spreadsheet.

Also of interest is Alex Boterolowry’s TurboX2 frontend for XMMS2. TurboX2 is a TurboGears web-based front end for the XMMS2 media player. From a code perspective, it features a number of interesting JavaScript bits that use MochiKit. These include a lazy list loader that will load in additional information as the list is scrolled. Even cooler sounding is an event loop that is designed to pick up and react to data that comes in from the server.

I’d be interested in hearing about other neat Python Summer of Code projects that went on.

There can’t be only one.

I guess I’d better give up now. Guido announced at SciPy that Django is the “standard” web framework for Python. How’s that for a first two sentences of a blog post? Of course, only one of those two sentences is accurate.

According to the blog post I linked to above, Guido “hopes that Django and TurboGears will converge”. Sigh. Someone please tell me that Guido hasn’t fallen for the “Python is losing to Ruby because Ruby only has one web framework” argument. I’m pretty sure he hasn’t fallen for that argument, but just generally thinks it would be a good thing. Django and TurboGears converging would be very much akin to Python and Ruby converging (Tim O’Reilly would probably advocate that, since book sales indicate that Python is waning). They address similar problem spaces and even have some similar approaches in spots, but that’s really a superficial view of the whole.

Guido’s attraction to Django started with Django’s template engine. He compared it with Cheetah and said, toward the bottom:

I didn’t find too many other templating solutions. TurboGears uses Kid which XML-based, like Nevow, TAL etc. IMO these are no contenders because they are XML-based. As the Django folks mention, they use templates to generate non-HTML text files as well. And even if they could be used for this, the verbosity of the XML syntax and the inability to do a proper if-then-else in XML make template writing using XML a non-starter.

For generating HTML, I find Kid to be a natural fit. I think it’s more natural than TAL and Nevow because the programmer just puts standard Python expressions in the right places in their templates (rather than some other kind of expression). Being able to write good, clean XHTML and produce fine HTML for the browser is a great feature and a great way to work. In practice, because I don’t go overboard writing code in templates, so if-then-else has not been a real problem. And, Markup shows a fairly clean way to do it anyhow.

And, certainly, generating non-HTML text files with Kid is suboptimal. First of all, I’d say again that this is not actually a big problem in practice. Seriously. It’s just not something that comes up much on the mailing list. Besides, TurboGears makes it trivial to use one of many other template languages (including Django’s) for generating non-HTML formats. In fact, you can even do it in one method:

@expose("cheetah:myproj.templates.textstuff", accept_format="text/plain")
def index(self):
    return dict(foo="5")

When you hit that controller method, by default you’ll get that dictionary plugged into the Kid template to produce HTML. If your browser sends an “Accept: text/plain”, TG will have Cheetah use the same code to generate a plain text view. Nice, huh?

TurboGears has a collection of APIs and idioms that I think make it great fun to work with, and I know others agree with me. Django has its own collection of features that others like working with. That’s fine by me, and it’s not likely to change any time soon.

With TurboGears, I definitely do not suffer from Not Invented Here. In Django’s defense, at the time they started they simply didn’t have the options available that I did when I started TurboGears. But, the Python community continues to evolve, innovate and produce incredible products. TG will benefit greatly from these projects, but it’s unclear that Django would follow suit.

Mike Bayer’s SQLAlchemy, simply put, kicks the butt of Django’s ORM (and that of Rails, as well). SQLAlchemy is already a solid second-class citizen in TurboGears, and will be a first-class citizen soon enough. Christopher Lenz saw the good in Kid and thought he could build a better Kid with Markup. Though it’s a young project, it looks great and has impressive results. Julian Krause liked CherryPy’s quick-and-easy URL traversal, but wanted to break it down to a WSGI core so he created RhubarbTart. Meanwhile, Robert Brewer has completely retooled CherryPy’s easy “filters” feature for CherryPy 3.0. And, for those who like their URL traversal in separate files with regexes, there’s always Ben Bangert’s Routes.

All of the things that I mentioned in that paragraph are not vaporware. With the exception of RhubarbTart, these are things that you can use with TurboGears now and that will likely be included directly with a future TG release. TG has had code contributions from quite a few people, but these things are all steps forward that have occurred completely outside of TurboGears but remain a natural fit for TG.

At EuroPython, during the Web Framework Shootout, we (Simon Willison, Phillip von Weitershausen and I) were taking questions from the audience and someone asked if we thought that TurboGears and Django would merge. My response now is the same as it was then: not very likely. Both projects have their own ideas and approaches and trying to force fit them just wouldn’t work.

Today’s TurboGears 0.9a9 release will likely be the last 0.9 alpha before 1.0 beta 1 comes out. Though many TurboGears users have been running the 0.9/1.0 code for some time, I’m looking forward to finally unveiling it more here, on and in “Rapid Web Applications with TurboGears”. My thanks, as always, goes to the many TurboGears developers that make the project possible.