On Sun, Sep 2, 2018 at 7:31 AM <jens.troe...@gmail.com> wrote: > If requests during their life cycle 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.
This is thinking about it the wrong way around. The best solution is to add a 'request' argument to those functions, or the specific request subobject they need. Sometimes you can't because you have to pass through a function that wasn't written for Pyramid, but that's what the threadlocal functions are for. Pylons had a magic request object and a magic "template variables" object that the subfunctions could import; they were threadlocal proxy stacks behind the scenes. That was to replicate the popular behavior in Myghty (definitely) and Rails (I assume). But they caused a lot of problems and were more trouble than they were worth. So it was considered an improvement when we migrated to Pyramid which passes an explicit request object instead. Why would you want to go back to threadlocals? Even if it sometimes uses a threadlocal function to find the Zope registry; I consider that a flaw rather than a feature.Semantically the subobjects are REQUEST-local, not THREAD-local, so why not treat them that way? -- 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/CAH9f%3DuqbPgFDfT5Tjod%3D73xNe3tdcHzFMwgmkjAnTw-6MyUqOQ%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
