Datasheet

Chapter 1: Web 2.0, Python, and Frameworks

This is often called metaprogramming , which refers to programming structures that operate on other pro-

gramming structures. Another way to think of the Python frameworks covered in the following chapters

is that they are code that writes code, or even self-modifying code.

As a Python programmer, you may have come across one or two such structures in Python, even if you

aren’t a master of metaprogramming. The addition of decorators in Python 2.4, which are lines of code

preceded by an

@ (at sign), make metaprogramming much less of a mystery and really easy to use. A

decorator is a function that takes a method as an argument and returns a method (or method-like) object.

The Python interpreter generally ignores decorators, but the signs are meaningful to TurboGears,

which has over a dozen of them and uses them as part of its controller structure. (Django doesn’t use

this approach.)

When you mention self-modifying code to most developers, you may evoke a shiver and some whis-

pered words of deprecation, but if it’s used correctly and in the right places (as with the frameworks cov-

ered in subsequent chapters), such code can lead to some very clean programming, or at least, from your

standpoint, very clean-looking code. But don’t forget that Python presents broader capabilities to write

this type of code than almost any other mainstream language in use today. Long before TurboGears, you

could dynamically modify any Python object by adding a new attribute to an instance of an object, or

dynamically acquire new methods and add those to an instance.

In contrast to Ruby on Rails, which is almost another language than Ruby, both Python frameworks cov-

ered in this book require you to make minimal changes in coding style versus writing normal Python

methods. For example, a TurboGears controller method has an

expose decorator right before the func-

tion, which designates the template to be used and returns a Python dictionary filled with the values to

be plugged into the template — everything other than that looks just like normal Python code.

You’ll find a similar method at work in the Kid templating language, which uses a mixture of standard

HTML and some special constructs as a Pythonic control language within the template. Another place

you’ll see special syntactic constructs at work is in MochiKit, which although implemented atop

JavaScript, has method calls and other constructs that look remarkably (and by design) like Python code.

In Chapter 12 you’ll see the ultimate pairing of DSLs. That chapter explores the mating of Flash ( Adobe’s

DSL for creating compelling user experiences) with TurboGears. By the end of the book, you will become

very familiar and comfortable with the general idea of DSLs as a way to make simple things easy and

hard things possible.

Leveraging the Power of TurboGears

By the definition, TurboGears can arguably be called a domain-specific language. What makes its use

compelling is that TurboGears is one of a new generation of Web 2.0 frameworks. In this context, the

term framework means software that enables you to write full-scope software. When people talk about full

scope , they mean that all aspects of a rich Internet application are addressed, from the user experience,

through the controller logic, to the underlying data model.

So why use a framework at all — why not just write dynamic HTML, server logic, and a database han-

dler in straight Python, or Java, or [ insert name of favorite language here ]? The answer to that is the same as

it’s always been. For every level of abstraction you can move up in software development, you gain an

ability to encompass greater complexity.