Warum verwendet Pylons StackedObjectProxies anstelle von threading.local?

Question

Es scheint, dass threading.local einfacher und robuster ist.

Answer 1

StackedObjectProxy verwendet darunter ein threading.local. Pylons verwendet keine einfachen threading.locals aus 2 Gründen:

1) Es wäre eine aufdringlichere API als ein Proxy. z.B. request().POST.get('file') vs request.POST.get('file')

2) StackedObjectProxys sind nicht nur threadsicher, sondern auch "request-sicher" - das bedeutet, dass es für eine Pylons-Anwendung sicher ist, in eine andere eingebettet zu werden und auf dieselben Proxy-Objekte zu verweisen. Der Bedarf an dieser Art von Sicherheit ist selten, aber mit der leichten Möglichkeit von WSGI-Apps, andere WSGI-Apps aufzurufen + die Verwendung globaler Objekte ist sie sicherlich eine Möglichkeit

Siehe die paste.registry-Dokumentation für weitere Informationen

Answer 2

Weil threading.local neu in Python 2.4 ist. Der StackedObjectProxy verwendet threading.local, wenn es kann.