On Sun, 2010-11-07 at 01:30 -0700, Mike Orr wrote: > > Also, if "stacked proxy globals" were such a big problem, why still > > have them? When I saw "configurator.start()" I immediately could smell > > something fishy. Just the fact that you have "doer" classes ending > > with "or" and having methods like "start" and "stop" tells a lot. This > > may not be that bad, but not SPECTACULAR, and spectacular is what you > > needed to justify killing of Pylons. Pylons was __amazing__, it just > > needed a better form handling package. > > I don't like them either. It's a deprecated backward-compatibility > feature for old BFG apps, as it says clearly in the manual. But it's > not worth rejecting the codebase over one minor flaw. > > ChrisM, can we just delete the threadlocal code now? Pyramid is a new > framework; it doesn't have to support all the old misfeatures in BFG's > history. Like Python 2 -> 3, and Pylons 0.9.7 -> 1.0. I also was > turned off by the threadlocals: it's something we wanted to get away > from in Pylons 2. It's not the "start" and "stop" methods that's the > problem, but the fact that users don't know how much overhead the > threadlocal code is causing in terms of CPU cycles or lines of code > (for space-constrained deployments like embedded systems and GAE).
I don't think CPU cycles are as much of a concern as other issues (the overhead required to push and pop the threadlocal stack is minimal). The real issue is the tension between wanting thread local variables and not having them. In particular, being able to obtain the request as a thread local is terribly handy on occasion. I'm on the fence about it myself. The begin()/end() pair during configuration is a convenient punching bag for people who aren't going to use the system anyway, even if it made toast for them. While I think it's reasonable to get rid of that misfeature soon for "normal" configuration, I'm almost tempted to keep it just out of spite. ;-) (joking, but not really). In the meantime, it's very useful for BFG people to have one Pyramid release that is backwards compatible with a BFG release, or at least to which BFG apps can be ported in an automated fashion. I'll ask that we get at least one release like that out before making any BFG-incompatible changes. > Even if it's isolated in an unused module, it feels like the kind of > cruft we're trying to leave behind in Pylons 2. > > On the other hand, some applications need thread locals for their own > purposes; e.g., for database connections. So if it can be implemented > and/or documented as a general thread local mechanism, rather than as > singleton/magic variables, that would deflect these criticisms. 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 think this particular spelling is problematic, because programmers tend to want to put imports outside the scope of functions; the get_request() spelling on the other hand, while it does use a thread local, causes no such desire. It's a "plain old thread local" (if there is such a thing). - C -- 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.
