Pourquoi les Pylons utilisent-ils StackedObjectProxies au lieu de threading.local?

Question

Il semble que threading.local soit plus simple et plus robuste.

Answer 1

Pylons n'utilise pas de threading.locals simples pour 2 raisons:

1) ce serait une API plus intrusive qu'un proxy. Par exemple. request(). POST.get ('file') vs request.POST.get ('file')

2) StackedObjectProxys ne sont pas seulement sûrs pour les threads, mais aussi "sécurisé", ce qui signifie qu'il est sûr pour un pylône application à être intégré dans un autre et référencer les mêmes objets proxy. La nécessité de ce type de sécurité est rare, mais il est certainement possible avec combien il est facile pour les applications WSGI pour appeler d'autres applications WSGI + l'utilisation des objets globaux

Voir la paste.registry docs pour plus d'informations

Answer 2

Parce que threading.local est nouveau dans Python 2.4. Le StackedObjectProxy utilise threading.local s'il le peut. StackedObjectProxy utilise un threading.local en dessous de