Maybe some background… the reason why I asked the initial question is because a few (and a growing number of) request handlers are complex; that is, they call multiple function levels deep.
Now request.dbsession, for example, is SQLA’s current DB session tied to the request’s transaction. To get access to it, functions keep handing that `dbsession` reference around. As we now begin to tie more data managers to the request’s transaction, handing their context around convolutes the parameters handed to functions. So I thought it would be useful if much/all of a request’s execution context would be available through the current thread local <https://docs.python.org/3/library/threading.html#thread-local-data> memory. If requests during their life cycle <https://docs.pylonsproject.org/projects/pyramid/en/latest/narr/router.html> would derive from threading.local and initialize such a storage area upon construction (e.g. after tween ingress) and tear it down (e.g. after tween egress) then deeply nested function could still access a request’s context *without* the need to pass that context around in parameters. Would it make sense to use a custom request factory to implement such a thread local approach? Are there other recommendations, considering the warnings in pyramid.threadlocal <https://docs.pylonsproject.org/projects/pyramid/en/latest/api/threadlocal.html> ? -- You received this message because you are subscribed to the Google Groups "pylons-discuss" group. To unsubscribe from this group and stop receiving emails from it, send an email to pylons-discuss+unsubscr...@googlegroups.com. To post to this group, send email to pylons-discuss@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/pylons-discuss/080f5943-b2df-4d6c-8b49-ab5cfa7bbe6c%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
