Why does Pylons use StackedObjectProxies instead of threading.local?

Question

It seems like threading.local is more straightforward and more robust.

Answer 1

Because threading.local is new in Python 2.4. The StackedObjectProxy uses threading.local if it can.

Answer 2

StackedObjectProxy uses a threading.local underneath it. Pylons doesn't use plain threading.locals for 2 reasons:

1) it'd be a more intrusive API than a proxy. E.g. request().POST.get('file') vs request.POST.get('file')

2) StackedObjectProxys are not only thread safe, but also "request safe" -- meaning it's safe for a Pylons application to be embedded in another and reference the same proxy objects. The need for this kind of safety is rare, but is certainly a possibility with how easy it is for WSGI apps to call other WSGI apps + the use of global objects

See the paste.registry docs for more information