In case you missed it… Pylons 0.9.4.1 was released back in January. Never used Pylons? Here’s the blurb:

Pylons combines the very best ideas from the worlds of Ruby, Python and Perl, providing a structured but extremely flexible Python web framework. It’s also one of the first projects to leverage the emerging WSGI standard, which allows extensive re-use and flexibility — but only if you need it.

I have yet to use it in any significant way, but Pylons does some really cool stuff. Check it out.

Yesterday I mentioned James Bennett’s discussion of the two camps of Python framework design. Ian Bicking has responded to James and seems to disagree.

Quoth Ian in his Full Stack vs. Glue post:

In a recent post on Framework design James Bennett describes as a fundamental dichotomy in framework design
“full-stack” vs. “glue”. In this case, Django (which James works on) as a full-stack framework, and TurboGears and Pylons as glue frameworks. This is not a good way to describe the differences.

He then discusses “awkward glue and easy glue”, the “intent” of the pieces, and “coupled” versus “decoupled” frameworks. Read the whole thing.

I have to admit that I tend to agree more with James on this one.

Sure you can get all nuanced and discuss the subtle differences in terms for each program design element… but when it comes down to it, the glue vs. full-stack gets the point across. For better or worse, some frameworks glue together existing parts (e.g. TurboGears and Pylons), and some write the whole thing from the ground up as a full-stack (e.g. Django).

There is nothing inherently wrong with either approach. And if you ask me, having two competing ideas is a Good Thing. I’d expect the invisible hand to deliver us even better frameworks in the future. So does the nomenclature really matter?

James Bennett’s The B-List is quickly becoming one of my favorite blogs. Today he has a very clear-headed post regarding Python web framework design. It’s long, but if you are at all interested in the TurboGears vs. Pylons vs. Django debates… it is well worth reading the whole thing.

Dave Kuhlman’s Pylons Quick Site Development page looks like a great crash course in building Pylons based web apps.

I know that Django is the framework that seems to get all of GVR’s love and all the buzz, but there’s something about Pylons that always seemed good to me. I’ve honestly never used it to any extent where I could really say much about it, but I really think it’s worth checking out… even if you decide it’s not right for you.

Simon Willison links to a technical comparison of TurboGears and Pylons by Ian Bicking.

Quoth Ian:

You’ll note there’s not a lot of high level philosophical differences. And I don’t think I glossed over that — they just aren’t there. The details of their differences are very… detailed. Very technical, very specific, often not particularly intentional. I’d have a hard time describing the technical differences in a meaningful way to someone who didn’t already know something about Python web development.

A well done comparison overall.

Related: Too much politics for programmers

KwangErn Liew asks which web framework is the best?

Update: Fixed the link.

Apparently MochiAds is built using everything but the kitchen sink:

For the technically inclined, the UI for MochiAds is built with Pylons, Genshi and SQLAlchemy. The secret sauce is a combination of Python and Erlang code, and we’ve got Nginx as the gatekeeper. I’ve got nothing but good things to say about this whole stack. Erlang’s module reloading, concurrency oriented programming model, and pattern matching has really been a dream.

Heh. Cool.

On Wednesday Ben announced the release of Pylons 0.9.3. This version includes a new, minimal template and bunch of bug fixes. Also, according to his post, there are now “lots of deprecation warnings so you know what to change before Pylons 1.0.”

In case you missed it, Pylons 0.9.2 was released in September.

In case you missed it, new version of Pylons was released in July.

Quoth Ben:

This version had some big internal changes, no longer using custom Myghty resolvers. We now use a very straight-forward WSGI interface to setup the application and the middleware. It’s easier to customize as a result, and the call-cycle is very understandable.

And it sounds like the strict adherence to WSGI minimizing compatibility issues.