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.