On Sun, Nov 7, 2010 at 6:02 AM, Chris McDonough <[email protected]> wrote: > In order to get a thread local managed by Pyramid, you have to call a > function: > > from pyramid.threadlocal import get_request > request = get_request() > > This differs from Pylons (and Flask) inasmuch as those two systems allow > you to do "from foo import athreadlocalvariable" (the purpose of a > "stacked object proxy").
I should add that I've long advocated the function syntax for Pylons. Quixote uses it, and it says clearly, "This function is doing something." It also provides an obvious place for the code that fetches the object. A plain ol' module attribute doesn't have a place for that code, which is wny one has to embed it in a proxy. But proxies can't emulate the object completely. Doing "dir(request)" in Pylons in Pylons won't show you the interesting request attributes and method names; it'll show you the proxy's attributes. You have to do the little-known "dir(request._current_obj())" to see the request methods. Chris, I'm sure you're aware that the SOPs are not just thread locals. They're thread-and-application-instance locals, in case you have multiple Pylons apps (or multiple instances of the same Pylons app) running in the same process. Because each application has its own 'app_globals' and 'config'. How do Pyramid's threadlocals handle multiple applications, or do they? -- Mike Orr <[email protected]> -- You received this message because you are subscribed to the Google Groups "pylons-discuss" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en.
