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. However, reading Why You Shouldn’t Abuse Thread Local <https://docs.pylonsproject.org/projects/pyramid/en/latest/narr/threadlocals.html#why-you-shouldn-t-abuse-thread-locals> (see the pyramid.threadlocal <https://docs.pylonsproject.org/projects/pyramid/en/latest/api/threadlocal.html> module) recommends against such an approach. Are there more recent and different recommendations? -- 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/5b86bb49-8fb5-4ebe-ad2b-c3a4da52bad3%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
