The newly-decorated function can then do things like checking the called arguments before invoking the original un-decorated function.

Django provides decorators for authentication so that you can wrap a view function with a check for client credentials before deciding whether to return the original response or a deny access.

In this manner Django’s authentication decorators encourage orthogonal code: the logic for displaying a view is separated from the logic for deciding whether you should be permitted to see the view’s output. By keeping them separate, it becomes simpler to re-use the authentication logic and apply it to other views.

Suppose you have a view that accepts a Django request object and checks whether the user is signed in:

def administration_page(request):
    if request.user.is_authenticated():
        return HttpResponse("Welcome, dear user.")
    else:
        return HttpResponseRedirect("/signin/")

With a decorator you can simplify and clarify things:

@login_required
def administration_page(request):
    return HttpResponse("Welcome, dear user.")

For older versions of Python (pre 2.4) which don’t understand the @ operator one must explicitly decorate the view function like so:

def administration_page(request):
    return HttpResponse("Welcome, dear administrator.")

administration_page = login_required(administration_page)

Note in the example that the original administration_page function is passed to the decorator. The @ syntax in the first example makes that implicit but the two are equivalent.

The implementation of a decorator is interesting. It takes the function itself as an argument and returns a new function which does the actual checking. Here is how the decorator used above might do its stuff:

def login_required(view_function):
    def decorated_function(request):
        if request.user.is_authenticated():
            return view_function(request)
        else:
            return HttpResponseRedirect("/signin/")

    return decorated_function

The actual implementation of Django’s login_required decorator is considerably less idiotic. Python’s functools module has helpers for writing well-behaved decorators.

Because functions in Python are themselves objects the decorator can accept a function reference, construct a new function that checks for authentication and then return a reference to that new function.

Simples!

(Simples gets less simples when you want to write a decorator that accepts configuration arguments because you then need either another layer of nested function definitions or a class whose instances can be called directly, but I’m going to ignore you for a bit and wow is that Concorde…?)

The Zen of Python states most of this in 19 lines, for all you tl;dr types.

Name-spaces and a minimal set of built-ins

I like that the set of keywords is small, and that the built-in methods are not much larger. This leaves you with an unpolluted name-space (and if you enjoy confusing people you can always override the built-ins).

Explicit versus implicit

Related to name-spaces is the notion that Python is explicit: there is very little magic in a Python script. Perhaps the closest thing to magic are the various special methods that define a behaviour, for example the __getattr__ / __setattr__ / __delattr__ methods on a class to control attribute access. But even then Python makes it obvious those methods have special meaning by using a double-underscore for the method names.

See the page on the data model in the Python documentation for a description of these methods and their purpose.

Generators and list comprehensions

I never realized how much I missed these until I went back to PHP for a small web project. So much of my code seems to be looping through lists and accumulating a result or applying a function to each member of the list. I don’t think the syntax is particularly obvious, but then I can’t think of a better way to do it. At first glance generators looked to be the same as list comprehensions, but eventually I began to understand the difference between needing a finite list of objects (list comprehension) and consuming a sequence of objects (generators).

Named arguments for methods and functions

Gosh, not having named arguments is painful. As a consumer, named arguments allow one to forget a function’s precise argument signature, and as a designer it allows one to provide sensible defaults and flexibility.

Dates and times as a native type

Well, not native, but readily available.

Python’s datetime module provides representations of calendar dates and times and a bunch of obvious behaviour for comparing two moments. PHP 5 introduced a proper DateTime class, but I had jumped ship a while before then – my affection for Python’s date handling is borne of a time when one had to rely on PEAR for useful date functions. Converting everything to seconds since the Unix epoch was never fun.

The greatest annoyance in Python’s date implementation is its shrugging support for timezones – you nearly always need to resort to a third-party module (such as pytz or python-dateutil) to handle timezones without jeopardizing one’s sanity.

Batteries included

It is odd that one does need an additional module to handle timezones seeing as the Python standard library includes so many useful modules for common tasks.

Need to work with CSV files? Or command-line arguments? Or Mac OS X-style .plist files? Or configuration files in INI format? Or tar archives (with gzip or bzip2 compression)?

Oh golly so much tedious work has been done for you in the Python standard library. I suppose this reflects PHP’s emphasis as a scripting language for the Web versus Python’s use as a general purpose language, but I am very grateful for that distinction.