Datasheet

Chapter 1: Web 2.0, Python, and Frameworks
13
Thus, a language that writes compact, dynamically typed code at a high level of abstraction is a big plus.
Additionally, Web 2.0 frameworks need to be able to create specific syntaxes that will speed RIA devel-
opment without getting in the way. As mentioned in the section “Leveraging the Power of DSLs,” a lan-
guage that enables dynamic self-modification through code that writes code is another important fea-
ture, and Python is among the few modern languages that excel in this regard.
Additonally, there are the attributes that you may already cherish. Python is often said to be a solid,
batteries included (in other words, complete ) language. Here’s why:
❑ It is solidly supported by a large and passionate community led by a pragmatic, benevolent
dictator.
❑ It is solidly designed to provide functional programming, object-oriented programming (OOP),
and metaprogramming.
❑ It is solidly deployed in countless contexts, from system administration to scientific
programming.
Finally, Python’s ability to integrate other libraries and components makes it an excellent gap-filling lan-
guage. It is perfect for automating the many tedious parts of Web 2.0 MVC applications. You should
have to write only the parts of your RIA that make it different and compelling, and not all the scaffolding
that every RIA must have. Those you will always prefer to delegate to a capable framework. Python
helps create the frameworks that make that possible.
Comparing the Frameworks
No parent ever wants to compare their children by saying that Caitlin is better than Sean (they’re both
better, just in different ways) and in this case the same is true. The Django and TurboGears frameworks
are each the best at certain things.
Both the Django and TurboGears frameworks implement a strict MVC design center and depend on
AJAX within the browser to invoke a server-side controller. Because they are both implemented in
Python, they both promote an agile development style. To choose the best one for your needs, consider
the differences presented in the following sections.
The Historical Perspective
Both the Django and TurboGears frameworks were motivated by observing that the component parts of
specific application implementations were good enough to make them generic. This opened them to the
possibility of reusability in other ongoing projects that were quite different from the original. Some of
you may recall that Python itself had a similar genesis. TurboGears sprang from an RCP RSS newsreader
client. TurboGears tends to be a little more dependent on the momentum of the open source community
than Django, simply because of the number of open source components that constitute its moving parts
(SQLObject, Kid, and CherryPy). Django originated in response to the need to produce a highly scalable
and dynamic online newspaper, one that gets millions of page hits per day.
As a result of the differing design centers, the Django team tends to focus on content management.
That’s a fancy way of saying that their concern is rooted in the need to create developer methodology