> > You are talking about these two lines of code > <https://github.com/Pylons/pyramid-cookiecutter-alchemy/blob/c84ab5bff19d6fbef9e36295cf3f74199b7a9a50/%7B%7Bcookiecutter.repo_name%7D%7D/%7B%7Bcookiecutter.repo_name%7D%7D/models/__init__.py#L59-L60> > in > the cookiecutter’s model/__init__.py, correct?
Right. Using that manager hook I can then derive from an explicit manager and > extend with custom functionality—and that would be the recommended way of > doing so? That may help me solve a question I just asked at the transaction > Github repo (see issue #62 > <https://github.com/zopefoundation/transaction/issues/62> there). Yes, if you don't have a consistent location in your code where you can push/pop threadlocals then you're going to have a bad time. For something like the `tm` you'd still be wise to use your own threadlocal manager that is set to explicit mode versus using the transaction.manager shipped with the transaction project. You'd probably make a manager and register an ISynchronizer that pushed/popped the threadlocal so that it's only available when a transaction is open. 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> > ? 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? Sure you could do this with a custom request factory. The recommendations are not "out of date", they are about general programming paradigms that you should avoid if you want to write testable/reusable code. Pyramid tries to avoid *forcing* you to use threadlocals anywhere - but it's not going to try to stop you if you want to do it. On Sun, Sep 2, 2018 at 9:42 AM <[email protected]> wrote: > 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 [email protected]. > To post to this group, send email to [email protected]. > To view this discussion on the web visit > https://groups.google.com/d/msgid/pylons-discuss/5b86bb49-8fb5-4ebe-ad2b-c3a4da52bad3%40googlegroups.com > <https://groups.google.com/d/msgid/pylons-discuss/5b86bb49-8fb5-4ebe-ad2b-c3a4da52bad3%40googlegroups.com?utm_medium=email&utm_source=footer> > . > For more options, visit https://groups.google.com/d/optout. > -- 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 [email protected]. To post to this group, send email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/pylons-discuss/CAKdhhwFh5QQ%2Biy94Vxmx1US1CG%3DFFhxCT7Hum-MAwhZ00UUwUw%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
