Concerning Python frameworks, Django is definitely my favorite ! I just found the frequency of the release a bit slow. A good start to evaluate other Python frameworks : http://www.therightsoft.com/softwaretechnologies/webframeworks/?languageid=2

(though as said before in the discussion, all the items are not comparable…)

you can download the django book(pdf) at bir2su.blogspot.com

First of all, the only deployment game in town is currently Mongrel, and the proposal is that you deploy 5 or so 30 meg Rails processes PER APPLICATION. So you have a bunch of little clusters popping up everywhere hogging all the RAM, and in lieu of a single server, they propose that this all be managed by a thing called Capistrano. I simply can’t do this.

I went back to Django after seeing the simple and familiar Apache prefork deployment on mod_python. Should be good enough. RoR/Mongrel is some kind of bandaid. Who thought of this per-app clustered architecture, at 30 megs a pop? Am I seriously willing to deploy that? Guess I’ll have to take a look…

Who knows though…maybe I’ll end up going back. Get to know Capistrano. Seems to me they’ve become as complex as Java. Hey, maybe I’ll just go back to Java.

TurboGears introduced the concept of “megaframework”, which Django and Pylons are also competing in. It looks like this has now become people’s concept of a “framework”, and the simpler frameworks are now… framework components?

The original definition of a framework was “it calls you” — i.e., a container for your application — as opposed to a library where is “you call it”. So all these server/dispatcher thingys are frameworks under this definition, including small ones like Paste and web.py.

Quixote is still maintained and in production sites. Its lack of activity is due to its stability as well as its minimalistic philosophy: fewer features means fewer bugs. The Quixote developers have chosen not to compete in the megaframework arena but instead to let people come to it. It does what its paying sponsors need, in any case. :) Future development has been targeted to Qpy, which has a more extensible codebase.

Nice to see that there’s a consensus. It wasn’t always this way, I believe.

“There are issues remaining with unicode, but at this point its primarily a Python problem (and in some cases, a database problem, like MySQL which can present some encoding challenges); strings are still represented as bytestrings by default, and converting into unicode objects can be tricky.”

Ignoring the database issues, which can be awkward, the “tricky” part of converting byte sequences (plain strings) into characters (Unicode) is hardly a “Python problem” unless that’s a label for the work that framework developers don’t want to do: it’s a fundamental part of interpreting the data. Python 3000 doesn’t magically solve this for you because the issues don’t go away with Python 2.x. Instead, they reside in the nature of the data the framework is busy pumping backward and forward on your behalf - precisely at the point where the framework should be lending a hand.

I didn’t bother exposing data as Unicode in WebStack for some time, mostly because I used the excuse that it was but a thin wrapper over other frameworks, but having full Unicode support for Java Servlets and “pot luck” for all the CPython stuff was highly embarrassing - it would be like an XML toolkit giving you plain strings and making you do encoding conversions manually.

If I wanted to point the finger at a guilty party on the subject of Unicode, encodings, and so on, it’d be the people who wrote the HTTP specifications, along with the people writing the next generation of them who are probably more inclined to dream up fancy new form widgets than define unambiguous behaviour. Nevertheless, other people have considered such matters before, and it isn’t particularly sensible to just ignore their work, even if they aren’t the “cool” people any more.

Not really. Pylons and Turbogears recommend Genshi or Mako templates which are both built for Unicode from the ground up. SQLAlchemy, used by both, can represent tables in Chinese (not just the data; the schema).

There are issues remaining with unicode, but at this point its primarily a Python problem (and in some cases, a database problem, like MySQL which can present some encoding challenges); strings are still represented as bytestrings by default, and converting into unicode objects can be tricky. That’s pretty much where the confusion comes from.

“It’s not all about momentum, you know - sometimes you want pieces of the stack to be stable, even mature. “

I dont find this to be true in the Java world either. A year ago, we were using Hibernate and Struts. Now we’re using JPA and Struts2 (which is an entirely different product); Hibernate’s API has been totally replaced, and Struts has literally been chucked wholesale. While we might want to look at Java for insight on how to handle things, my observation is that they have been looking at us (us being, Ruby and Python) a lot as of late, working at making their APIs more friendly, adding decorator-like “annotations” and iterator syntaxes, copying our ideas for web controllers, and cutting down on the XML bloat. I think the “stability”/”maturity” perception on the java side comes down to the sheer number of developers working on things over there (and being paid full time to develop them by big corporations). Whereas Python projects are often volunteer/part-time/not-really-funded ventures with much smaller userbases.

I think a lot of frameworks could start out by learning how the Java technologies manage to work with Unicode, given the widespread problems many Python-based frameworks have had with Unicode until very recently. I note that someone in the Django community eventually stepped up and dealt with the issue, but it probably still remains in other frameworks, given the occurrence of discussion threads on such matters in various places.

It’s not all about momentum, you know - sometimes you want pieces of the stack to be stable, even mature. The problem has been that everyone has wanted to show how much they’re innovating (which has indeed happened), but that can lead to egregious and ubiquitous breakage as the developers refine their work. You wouldn’t want your C library API to mutate every few weeks or months. Likewise, it’s a relief to be able to use technologies which improve but don’t break your code needlessly as they evolve, get updated or get fixed. (I don’t update WebStack very often at all, or at least not the central abstractions, but that doesn’t mean it doesn’t work any more, or that it isn’t useful for other components or applications.)

As for the Wiki page…

“It’s a horrible landing place for people looking to make a decision about a Python web framework. I was just trying to be helpful to readers by warning them about that.”

The dates next to the frameworks give the discerning reader a good indication of framework vitality, and I don’t even think that this was even my idea. Nevertheless, the page, which was previously a mess of links and opportunistic promotion, got an overhaul a while back after I got fed up with how incoherent it had become. Whether it plays an important role in informing people or not (or whether it represents the “new consensus” around Python Web frameworks as you see it), giving it the brush off is rather unfair to the people who update it (usually not me, unless I’m despamming it or making superficial edits) as well as the people who find it useful.