The Django docs are pretty clear on threadlocals. One good use I can think of for threadlocals is for Basecamp style subdomains.
This seems like a great way to use Django's sites framework, except it requires the SITE_ID to be set in the settings. You can use a middleware that uses threadlocals to set this per request, such as the one provided by django-multisite. This is mostly a drop-in solution, but requires you to think of where your querysets are being built.
Let's take the following example models:
from django.db import models
from django.contrib.sites.models import Site
from django.contrib.sites.managers import CurrentSiteManager
name = models.CharField(max_length=200)
active = models.BooleanField()
site = models.ForeignKey(Site)
on_site = CurrentSiteManager()
With the following form:
from django import forms
from models import Author
author = forms.ModelChoiceField(queryset=Author.on_site.filter(active=True))
Unfortunately, this may not work. The queryset will be built using the SITE_ID that is in effect when the form class is declared, resulting in the same SITE_ID being used process-wide.
You can enforce the SITE_ID to be evaluated in the proper context, assuming you aren't doing anything tricky, by changing the queryset upon the form initialization.
author = forms.ModelChoiceField(queryset=Author.objects)
def __init__(self, *args, **kwargs):
super(ExampleForm, self).__init__(*args, **kwargs)
self.fields["author"].queryset = Author.on_site.filter(active=True)
This is just one example of how values in threadlocals may yield application errors when you aren't aware of the context the code is executed in.