问题
It seems like threading.local is more straightforward and more robust.
回答1:
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
回答2:
Because threading.local is new in Python 2.4. The StackedObjectProxy uses threading.local if it can.
来源：https://stackoverflow.com/questions/1686768/why-does-pylons-use-stackedobjectproxies-instead-of-threading-local