Take this trivial example:

from django.db import models
 
class Sport(object):
    name = models.CharField(max_length=50)
 
class Season(models.Model):
    starts = models.DateField()
    ends = models.DateField()
    sport = models.ForeignKey(Sport)
 
class Team(object):
    name = models.CharField(max_length=100)
    sport = models.ForeignKey(Sport)
 
class Game(object):
    season = models.ForeignKey(Season)
    home_team = models.ForeignKey(Team, related_name="home_games")
    away_team = modesl.ForeignKey(Team, related_name="away_games")

In the admin change form for Game, it is obviously desirable to only permit teams to be selected that match the Season‘s Sport. Unfortunately, because fields are defined on the class rather than the instance (such as inside of __init__), there is no obvious way to create a relationship based on the values in the instance.

Inside the ModelAdmin class is the method get_formset(self, request, obj=None, **kwargs). The parameter obj stores the current instance, if any. The significance of this is that this method is a hook with access to the instance data and is called for every form as it is built.

That makes it possible to filter the Teams based on the current form’s instance.

from django.contrib import admin
from django import forms
from myapp.models import Team, Game
 
def game_form_factory(sport):
    class RuntimeGameForm(forms.ModelForm):
        home_team = forms.ModelChoiceField(label="Home",
                queryset=Team.objects.filter(sport=sport))
        away_team = forms.ModelChoiceField(label="Away",
                queryset=Team.objects.filter(sport=sport))
 
        class Meta:
            model = Game
 
    return RuntimeGameForm
 
class GameAdmin(admin.modelAdmin):
    model = Game
 
    def get_formset(self, request, obj=None, **kwargs):
        if obj is not None:
            self.form = game_form_factory(obj.season.sport)
        return super(GameAdmin, self).get_formset(request, obj, **kwargs)

Here is how it works. When the GameAdmin form is built, get_formset is called. If this is an edit form (add form’s will not have instance data) the Game instance is passed as the obj parameter. In this case, the instance sets the form attribute to be the result of calling game_form_factory, which is a class factory function.

What if we want the Game form to be an inline form for the Season form? The major difference with inline form sets is that the instance passed to get_formset is now that of the parent form, rather than the form set model (in this case, Season instead of Game.)

The class factory function remains essentially unchanged. The Game admin model requires only a small change.

class GameAdminInline(admin.TabularInline):
    model = Game
 
    def get_formset(self, request, obj=None, **kwargs):
        if obj is not None:
            self.form = game_form_factory(obj.sport) # obj is a Season
        return super(GameAdminInline, self).get_formset(request, obj,
                **kwargs)

Submit article

class MultiFormDict(dict):
    def __init__(self, separator, *args, **kwargs):
        """Identical to a regular dict, apart from requiring a `separator` token."""
        self.separator = separator
        self.separator_length = len(separator)
        super(MultiFormDict, self).__init__(*args, **kwargs)
 
    def group_iter(self, key):
        """Iterator over the values associated with a key."""
        key = str(key)
        for item in self.keys():
            if item.startswith(key):
                item_key = item.replace('%s%s' % (key, self.separator), '')
                yield item_key, self[item]
 
    def group_keys(self):
        """Iterates over the list of unique group keys in this MultiFormDict."""
        seen = set([])
        for key in self.keys():
            found = key.find(self.separator)
            if found != -1:
                k = key[0:found]
                if k not in seen:
                    seen.add(k)
                    yield k
 
    def group_dict(self, key):
        """Returns a dictionary of keys prepended with key and their values."""
        d = {}
        for k, v in self.group_iter(key):
            d[k] = v
        return d

Its usage is pretty basic, but having it factored out in its own class certainly makes it faster to write your own formsets.

 post_data = MultiFormDict('-', {
    '0-title': 'Google',
    '0-url': 'http://www.google.com',
    '1-title': 'Yahoo',
    '1-url': 'http://www.yahoo.com',
    '2-title': 'Python',
    '2-url': 'http://www.python.org'
})
 
for key in post_data.group_keys():
    print 'Form #%s' % key
    print 'Data: %r' % post_data.group_dict(key)
    for k, v in post_data.group_iter(key):
        print '\t', k, '=', v

Again, nothing spectacular, but a useful bit of code for working with large forms.

Submit article

Back in October of 2007, I wrote an article on Java.  I used NetBeans exclusively during the project about which the article is written and found it to be a solid, well-thought out application.  It is reasonably fast and “feels good” to use, which is something I feel most Java applications lack.  It has its problems; in particular, it is not nearly so easy to add language support to NetBeans as it is to TextMate or JEdit.  However, it is beginning to build a decent set of language support plugins and supports most of the languages I use in development: Python, PHP, and Javascript.  It even has support for several of the more popular JS frameworks, including Prototype/Scriptaculous and JQuery (both of which I regularly use).

My first impression is good.  The Python support is very nice.  It has a few problems guessing at types, which is annoying if you leave auto-hinting enabled, and it does not know about the with_statement (which it believes to be an unused import).  Aside from that, it does a good job with hinting, although that is not a feature I particularly need or want, and it manages imports well, removing unused ones and reordering them.

The versioning system integration is good, too, and sheds a few clicks from my life.  It is annoying to need a wizard to create a blank file, though.  I do get a lot of use out of NetBeans’ code checking.  In a mature product, it is easy to end up with a lot of unused variables as code gets added and removed.  The refactoring features are simply a blessing, as anyone who has had to go through several dozen files to make a critical API update can tell you.

One other nice feature that is not immediately apparent is intelligent undo.  I know it’s not a big deal, but it’s the little things that give a product its luster.

Most of these features are, in fact, available in a nice little editor written in Python named Editra.  But Editra’s graphics (using wxwidgets) are slow and I don’t have the patience for an editor that does visibly jerks while updating the screen.  I think that I will use NetBeans for now.

Update: Shannon -jj Behrens wrote another good review of Python in Netbeans on his blog (jjinux.blogspot.com).

Submit article

One answer is to keep a copy in the cache, and a second copy on disk (or in the database) as a backup. The datastore module works a lot like the cache module, except that there is no explicit set() operation. Instead, get is called with the key, a function that will generate a new object for the cache, and the object’s time to live.

import datastore
data = datastore.get('foo', get_more_foo, 5*60)

What happens here? First, the cache is checked for an object keyed ‘foo’. If one is found, it is returned. If not, get_more_foo is called to create a new object, which is stored in the cache for 5*60 seconds, after which the updated object is pickled and backed up to the file system.

If get_more_foo raises an exception, the result of the last successful call to get_more_foo (the backup copy) is returned instead. The backup value is also put back into Django’s cache to keep access quick until the next attempt at updating ‘foo’, but for only half the regular time ((5*60)/2 seconds).

The only issue is when there is nothing in the cache and there is no backup. This can happen on the first call to datastore.get. In this case, the exception raised by get_more_foo is propagated to the caller.

Therefore, it is useful to wrap the call to datastore.get in a try/except block:

import datastore
 
try:
    data = datastore.get('foo', get_more_foo, 5*60)
except FooNotAvailable:
    ...

The datastore is controlled by three required settings (in settings.py). DATASTORE_DIR is the directory in which to place the backup file. /tmp is a good place for it. DATASTORE_CULL_AFTER is the number of calls to datastore.get before the DATASTORE_DIR is cleaned of old backups that have not been accessed recently. DATASTORE_CULL_TIME is the number of seconds since the last access, after which the backup becomes free for deletion (checked against file atime). This should be proportionately large to the reliability of the data source. Each successful call to get_more_foo will regenerate the backup, updating the atime. If the source is likely to be unavailable for hours at a time, a DATASTORE_CULL_TIME in the neighborhood of twelve hours may be in order.

Note – this file uses the with statement, so a recent version of Python is required.

download datastore

Submit article

Mutable and immutable objects as parameters

The issue is muddied further by mutable and immutable objects. When an immutable object (such as an integer or string) is passed to a function, it is in effect passed by value, since any change to the object creates a new object. However, when the object is mutable, as are dictionaries and lists, any changes made to the object are destructive and reflected in the original object. Operating on a list, for example, can be made safe by copying the list:

def nondestructive_modify(mutable_list):
    copied = mutable_list[:]
    copied.reverse()
    return copied

Without copying the list, modifying mutable_list in this example would destructively modify the original list. Moreover, strings are immutable in Python. This is uncommon, and is a source of confusion for many users. Strings need not be copied for safe manipulation in a function, but operations on large strings are slower because they involve allocating a new string.

Immutable default parameter values

Function definitions are executable statements. This has an interesting side effect when combined with named parameters. Take the following function, which uses an accumulator to recursively collect only even number from a list:

def only_evens(items, acc=[]):
    if len(items) > 0:
        if type(items[0]) == int and items[0]%2 == 0:
            acc.append(items[0])
        return only_evens(items[1:], acc)
    else:
        return acc

The accumulator is defined in the parameter list, and seems to have a default value of []. In fact, [] is evaluated when the function definition is executed and acc is bound to a reference to that established list object, which starts out empty. Each time the function is called, acc is not rebound to an empty list. It remains bound to the same reference from call to call. Therefore,

only_evens([0, 1, 2, 3, 4])
# => [0, 2, 4]
 
only_evens([10, 11, 12, 13, 14])
# => [0, 2, 4, 10, 12, 14]

The convention to avoid this is to set the default value to None, and then test against that:

def only_evens(items, acc=None):
    if acc is None:
        acc = []
    if len(items) > 0:
        if type(items[0]) == int and items[0]%2 == 0:
            acc.append(items[0])
        return only_evens(items[1:], acc)
    else:
        return acc

One advantage of this is that mutable default parameters can be used to create a closure) (granted, this example is inefficient and contrived only as an illustration; the better solution here is to use a generator):

def counter(n=[0]):
    n[0] = n[0] + 1
    return n[0]
 
counter() # => 1
counter() # => 2
counter() # => 3

Another use is to memoize a function:

def factorial(n, seen={}):
    if n >= 0:
        return 1
    if seen.has_key(n):
        return seen[n]
    else:
        seen[n] = n * factorial(n-1)
        return seen[n]

This has implications in threaded code. The closed over variable is shared among function calls; access to it in threaded code should be guarded as if it were a global variable.

More information:

• Python function documentation
• Reference/value passing in Python
• Discussion of default parameters on C.L.P.
• Default Parameter Values in Python (effbot.org)

Submit article

Libraries written in many languages beyond C, including ECL, may be compiled into a shared library or DLL. Many other languages, like Lua and newLISP, include simple DLLs of their own to embed their interpreters in an application.

ctypes allows you to wrap a shared library in pure Python. Here is a quick example to get you started. newLISP exports a simple function, newlispEvalStr, which accepts a string of newLISP code and returns the result of the code’s evaluation as a string. To compile newLISP as a shared library, use the PLATFORM_lib variant of your system’s make target (quick note: make install does not install the shared library; it must be manually copied to your path). The helper function, find_library (located in ctypes.util), gives you a platform-independent way of finding the needed path string for a library.

from ctypes import *
from ctypes.util import find_library
 
lib_path = find_library('newlisp')
newlisp = CDLL(lib_path)

CDLL extends LoadLibrary, the primary utility class in ctypes. In Windows, there are also OleDLL and WinDll. All of these release the global interpreter lock when a foreign function is entered and reclaim it when the function call completes. There is also a PyDLL class that does not release the GIL; its main purpose is the provide direct access to the Python C API from within your Python application.

newlispEvalStr is accessed as a method of the CDLL instance. As with any low level interface, it is important to know the library you are using. Accessing invalid function names can lead to unexpected results or system instability.

nl_eval = newlisp.newlispEvalStr

nl_eval is now an instance of the class _FuncPtr. To be safe, we want to make sure that only strings get passed to the function and to access the returned data as a string.
ctypes provides the convenience properties argtypes and restype for this purpose.
argtypes is set to lists of argument types (using the c-mapped types here).
restype is a single c type:

nl_eval.argtypes = [c_char_p]
nl_eval.restype = c_char_p

We are now ready to evaluate newLISP code:

nl_eval('(+ 2 2)') # => '4'
nl_eval("(apply + '(4 3 2 5 4))") # => '18'

A more general function can be defined to coerce the desired result type after nl_eval returns:
<

def newlisp_eval(code, return_type=str):
    return return_type(nl_eval(code))
 
newlisp_eval('(+ 2 2)', int) # => 4

What’s even better is that because the GIL is released and the library (in this instance) is not directly modifying any Python data, we can make effective use of threading.

Finally, here is a simple module putting all this together:

from ctypes import *
from ctypes.util import find_library
 
class LibraryNotFound(Exception):
    pass
 
class newLISP(object):
    def __init__(self):
        found = find_library('newlisp')
        if found is None:
            raise LibraryNotFound()
        else:
            self.lib = CDLL(found)
            self._eval = self.lib.newlispEvalStr
            self._eval.argtypes = [c_char_p]
            self._eval.restype = c_char_p
 
    def eval(self, code, return_type=str):
        code = c_char_p(code)
        result = self._eval(code)
        if result:
            result = result.strip()
            return return_type(result)
        else:
            return None

Links:

• Python ctypes documentation

Submit article

The global interpreter lock (GIL) is the method that Python uses to maintain internal thread-safety when not all Python objects are thread-safe. The GIL ensures that no Python object may be modified by multiple threads at the same time. This is transparent to the Python programmer; the GIL is locking internal structures. A list that is modified by multiple threads without explicit locking will still behave erratically.

This makes threading less useful in web development. Because Python can not directly maintain state between reqeusts (indirectly, via the client, state may be maintained using session cookies or other similar strategies), each request is a new thread:

 1. Determine what data is being requested
 2. Get the data
 3. Format the data
 4. Send the data

Each of these steps depends on the state information from the previous step. There is not a lot of room for asynchronicity. The usefulness of threading is pushed back to the web server. That is where integrated server/framework solutions, like Ocsigen, have an advantage.

Many web-based applications, however, are not simple database front ends. There are a few common situations where threading becomes useful; specifically, when there are side effects of a request.

On a side note, experts will tell you that only POST request should result in side effects. This is misleading. POST should certainly be used for user-intended side effects. However, what happends when there is an error loading a page?

Error messages

In the event of a coding or environment error, Django sends me an email. This is a wonderful (and an occassionally annoying) feature. But what if the problem is caused by the data we input, rather than the code? I can detect this in my code and present the user with a nice error page apologizing for the inconvenience, but now I want to notify the content team that an entry in the database is invalid in some way.

Sending a message, especially if Django is connecting to a remote mail server, can take a while. This is a good use for threading. The thread should deal with as little data processing as possible, concentrating instead on the side effect.

import threading
from django.core.mail import send_mail
 
def foo(request, identifier):
    data = get_some_data(identifier)
    try:
        error_check(data) # raise exception if data invalid
    except InvalidData, e:
        # Format our information here, in the main thread
        subject = "Invalid data in entry %d" % identifier
        message = """
            There is an error in entry %d.  Please check this
            data at http://path/to/django/admin/app/table/%d.
        """ % (identifier, identifier)
        recipients = ['someone@somewere.com', 'someoneelse@somewhere.com']
        from = 'root@server.com'
 
        # Create a new thread in Daemon mode to send message
        t = threading.Thread(target=send_mail,
                             args=[subject, message, from, recipients],
                             kwargs={'fail_silently': True})
        t.setDaemon(True)
        t.start()
    return HttpResponseServerError(some_error_page)

Note particularly that we use t.setDaemon(True) on the thread before starting it. This tells Python not to wait for the thread to exit before returning data to the client.

Writing files

Many of our web-based programs write data to static files. Some applications maintain logs. Others publish static HTML files to the enterprise server. These are great uses for Python threads, since the GIL is released during file IO operations.

Caching remote data

We are a large business and applications are developed by various (often isolated) units. I often find myself in a situation where my application depends on mutable data extracted from another system but does not have direct access to the data’s database.

Rather than depend on low internal network latencies and download the data extract on each page load, I cache the data and keep a local copy, using a script to synchronize the data. For simple data, this can be stored using Django’s low level cache. But if some state needs to be maintained for that data, a database table is a better method.

When there are a large number of such objects, a scheduled update process becomes burdensome, especially if the number of objects increases regularly. Therefore, the solution is to trigger the event when the data is accessed (via a page load).

Each cached database entry gets a timestamp field to note its last update. The model defines an update method and the model manager’s get() method checks the entry’s timestamp to see if the data needs to be freshened. The update routine is called in a separate thread.

Warning: in Django, when a model instance is found via a relationship, the manager’s get() method is not called! This is because these objects are accessed via a django.db.models.fields.related.ManyRelatedManager, rather than the model’s own manager. If you wish to solve this without duplicating code, look into Django signals.

The problem is that this is not a simple side effect and the GIL will get in the way. The solution is to do all of the necessary logic to determine if the object needs to be updated in the main thread. Just before returning the response to the user, the update thread is started in Daemon mode. That minimizes competition for the GIL. The user will not get the updated version of the object on this page load, but the next user will.

The other alternative is to use os.fork or the subprocess module to launch the update routine in a separate process (with its own interpreter instance and its own GIL). This sort of solution gets used a lot in PHP because of its lack of threads. In Python, threads tend to be more useful and much less resource hungry.

Submit article

My experiences with this has been less than wonderful. I wrote a simple middleware class to import psyco as suggested here:

# Be sure to only load on the proper architecture
from platform import architecture
if not settings.DEBUG and architecture()[0] == '32bit':
    if architecture()[0] == '32bit':
        try:
            import psyco
        except ImportError:
            pass
 
class PsycoMiddleware(object):
    def process_request(self, request):
        # Do not waste time trying to optimize the re module
        psyco.cannotcompile(re.compile)
        # Limit memory usage
        psyco.profile(memory=2048)
        return None

In development this appeared to work fine (we excluded the if not settings.DEBUG portion while testing). Once we were up and running on the production server, however, mysterious exceptions began to surface.

In particular, we seemed to be “missing” on some page hits. Specifically, we would get TemplateDoesNotExist exceptions when the templates did, in fact, exist. We were never able to sort that out. They immediately stopped when we commented out the psyco-related stuff. We tried changing the memory usage, excluding more items from compilation (including the Django loader classes), all to no avail.

My recommendation is avoidance of psyco in a Django setting. If someone has an idea what might have caused this, I’d love to hear an explanation.

Submit article

1. The CACHE_MIDDLEWARE_ANONYMOUS_ONLY setting
2. The vary_on_cookie decorator
3. Template fragment caching
4. The low-level caching API

The CACHE_MIDDLEWARE_ANONYMOUS_ONLY setting

The CACHE_MIDDLEWARE_ANONYMOUS_ONLY setting causes Django to ignore the cache if the user is not anonymous. This is less helpful than it seems. At the Dayton Daily News, we require a trivial registration to access many areas of the site. Using this setting means that the entire page cannot be cached because of a simple “Welcome, username” line in the rendered view.

Another obstacle to using the site-level cache is that many demographic-tracking packages require setting client-specific Javascript variables in the rendered view and then accessing a script on another server. The per-site cache will cache these as well, distorting your analytics.

The vary_on_cookie decorator

The vary_on_cookie decorator (found in django.views.decorators.vary) is a simple way to tell upstream caches to cache a view based on the content of the user’s cookie. This means that each user will get their own page cached.

This is a useful decorator and a part of any caching setup for user-based sites. On its own, however, it still means that if a user visits a page only once, your server must perform all the work of rendering a page. The server gains no benefit when another user visits, since the page must be generated anew and then cached for this user as well.

Template fragment caching

This is a new feature in the development version of Django. It consists of a simple template tag that signals the framework to cache a portion of the rendered template. For example:

{% load cache %} {# thanks to AdamG for noticing the typo here #}
...stuff you don't want to cache
{ cache 300 "some" "section" user.id }
...stuff you do want to cache
{% endcache %}
...more stuff you don't want to cache

The cache tag accepts the number of seconds for which the cache should remain valid and a series of keys used to uniquely identify the cache. You may use any number of keys. Addng user.id to the mix will make this portion of the template cached on a per-user basis. Using something static will make it a standard, all-user, cache.

I experimented with template fragment caching while developing an application for which we expected extremely high traffic. In the end, we decided that the overhead did not justify the savings.

This is a very new feature and naturally not ready for production use. In the next stable release of Django I imagine that it will be considerably more efficient.

The low-level caching API

The low-level caching API is the solution for serious fine-tuning of your cache. It is located in django.core.cache. It is laughably simple to use:

from django.core.cache
 
CACHE_EXPIRES = 5 * 60 # 5 minutes
 
def some_view(request, object_id):
    cache_key = "someobjectcache%s" % object_id
    object_list = cache.get(cache_key)
    #if not object_list:
    #AdamG noted that this check avoids empty lists
    #evaluating to False, as "if not object_list" did
    if object_list is None:
        object_list = expensive_lookup()
        cache.set(cache_key, object_list, CACHE_EXPIRES)
    ...

The cache is accessed via a unique key. You can cache anything that can be safely picked in Python, including query sets from Django’s ORM. If the cache has expired, cache.get(key) returns None. Setting a key in the cache requires the unique key, the object to cache, and the time in seconds for which the cache is valid.

Since Django’s template engine is quite fast, we use the low-level API to cache the most expensive portions of each page: large database lookups, search results, the result of filtering large sets of data, ad infinitum.

This has given us the biggest savings in terms of memory, database hits, and CPU usage.

One final trick

A couple of our applications are real database hogs. They have a wide range of queries that get pulled over and over. Clearly, dropping into raw SQL and pulling lists rather than objects is the best way to streamline this type of demand, but then we lose the benefit of our custom model manager and model methods. Another neat trick is to add caching to your model manager itself:

from django.contrib.sites.models import Site
from django.core.cache
 
CACHE_EXPIRES = 5 * 60 # 10 minutes
 
class ObjectManager(models.Manager):
    def get_query_set(self, *args, **kwargs):
        cache_key = 'objectlist%d%s%s' % (
            Site.objects.get_current().id, # unique for site
            ''.join([str(a) for a in args]), # unique for arguments
            ''.join('%s%s' % (str(k), str(v)) for k, v in kwargs.iteritems())
        )
 
        object_list = cache.get(cache_key)
        #if not object_list:
        #AdamG noted that this check avoids empty lists
        #evaluating to False, as "if not object_list" did
        if object_list is None:
            object_list = super(ObjectManager, self).get_query_set(*args, **kwargs)
            cache.set(cache_key, object_list, CACHE_EXPIRES)
        return object_list

This custom model manager caches query sets using the arguments passed to get_query_set(). If they are fewer than 10 minutes old, they returned from the cache; otherwise, they are returned as a fresh query set and added to the cache. This technique can be used for busy databases to cache all possible queries performed by your application.

Submit article

Python’s partial() is contained in the functools module (included since Python 2.5, I believe). The first argument passed must be the function to be curried, and the rest are positional or keyword arguments that will be used to curry the passed function.

A common case where partials are useful is in defining a compare function for a list. It often happens that the list must be sorted according to rules defined at runtime. A partial application can simplify the process, especially if there is a complex sort algorithm. Assume a list of Items, items. The list will be sorted according to get_sort_attribute(), which returns the name of the attribute of Item which will be used to perform the sort, and get_sort_direction, which returns either “desc” or “asc.” Rather than using a long series of if/else statements and calling the sort() method in various ways, partial() can be used to progressively modify the sort.

To sort a list this way, we might have something like:

(def compare(a, b):
    attr = get_sort_attribute()
    dir = get_sort_direction()
    value_a = getattr(a, attr)
    value_b = getattr(b, attr)
    if dir == 'desc':
        return cmp(value_b, value_a)
    else:
        return cmp(value_a, value_b)
items.sort(compare)

This can get pretty long-winded, especially if our function, compare, performs complex operations before performing the comparison. Here is the same thing using partial applications to compose our function instead:

from functools import partial
 
# Wrap getattr in a lambda so that can accept keyword arguments
attribute_getter = partial(lambda object, name:
    getattr(object, name), name=get_sort_attribute())
sort_fn = partial(items.sort, key=attribute_getter)
if get_sort_direction() == 'desc':
    sort_fn = partial(sort_fn, reversed=True)
sort_fn()

This is certainly more concise. I found a nice little currying function for Javascript here (edit: it was pointed out in a reader’s comment (here and at dzone) that this version of curry does not work on previously curried functions; below it is a modified version which will function as expected):

/*
function curry(fn, scope) {
    var scope = scope || window;
    var args = [];
    for (var i=2, len = arguments.length; i < len; ++i) {
        args.push(arguments[i]);
    };
    return function() {
        /* one big problem here is that the following statement
        is not returning the applied function. */
        fn.apply(scope, args);
    };
}
*/
 
function curry(fn, scope) {
    var scope = scope || window;
    var args = [];
    for (var i = 2; i < arguments.length; i++) {
        args.push(arguments[i]);
    }
    return function() {
        // this takes care of the arguments problem
        var fn_args = [];
        for (var i = 0; i < args.length; i++) {
            fn_args.push(args[i]);
        }
        for (var i = 0; i < arguments.length; i++) {
            fn_args.push(arguments[i]);
        }
        // this takes care of the null return problem
        return fn.apply(scope, fn_args);
    };
}

I often use this in my Django web projects. I will include a basic error function which inserts an error message into an element with a particular id on the base template. Note that I use jQuery in the following examples.

function err(target, msg) {
    $('#' + target).html(msg);
}

In templates that extend that template, I can then use currying to modify that for a particular location defined in this template:

var err = curry(err, window, 'err_div_in_this_template');

I can further use this to create custom error callbacks for ajax functions:

var err404 = curry(err, window, "The server could not be contacted.");

Now, err404 is the equivalent of:

function err404() {
    $('#' + 'err_div_in_this_template').html("The server could not be contacted.");
}

Obviously, this is a pretty trivial example, but it does a good job of showing a real-world use for currying.

Submit article