On Tue, 2012-01-31 at 15:06 -0800, Mike Orr wrote: > On Tue, Jan 31, 2012 at 9:33 AM, Jonathan Vanasco <[email protected]> > wrote: > > I come from Pylons, where we had the g globals object. I miss it > > dearly. > > > > The Pyramid/Repoze group seems very much into the idea of passing a > > request around all the time. I don't like that, mostly from the 'mass > > appeal route' , in that its something that just about every other > > framework has, and can make Pyramid a bit odd/hard to new people > > considering it. > > Some frameworks have it and some don't. I've already explained why it > caused so much trouble in Pylons. > > > Anyways, if you need to do this again: > > > > The Akhet scaffold has an event subscriber that creates a 'g' globals > > object to emulate the pylons environment > > > > https://bitbucket.org/sluggo/akhet/src/6c984e2e24cf/akhet/paster_templates/akhet/%2Bpackage%2B/subscribers.py_tmpl > > > > or you could also just have a little convenience method that just > > wraps get_current_registry() > > def get_current_settings(field=None): > > if field: > > return get_current_registry().settings[field] > > return get_current_registry().settings > > Akhet doesn't have 'g', but you can inject 'g = > request.registry.settings' into the template namespace if you want. > I'm not sure if you misunderstood the file you linked to; the > 'renderer_globals' variable there is the template namespace, not a 'g' > variable. > > Chris McDonough wrote: > > The framework does not require that your application use globals. This > makes it possible to run more than one Pyramid application in the same > Python process, and makes it more likely that Pyramid can be used "like > a library", which makes creating things like a development environment > on top of Pyramid more pleasant. > > Pylons bent over backwards to support multiple Pylons applications in > the same process, and even multiple instances of the same Pylons > application. That's what really turned the globals into deep voodo, > and required StackedObjectProxies to ensure the correct global values > were visible to each request.
Pyramid also has the same concept of a stack; it's just not implemented like Pylons' SOPs were. The problem with SOPs was that they were *importable*. When you use the request or registry in Pyramid as a , you have to request it via get_current_request() or get_current_registry(), and if you try to do that at module scope, you get to keep both pieces when it breaks. In Pylons, because SOPs were importable, people had the expectation that they were useful at module scope, and got wrapped around the axle when they were sometimes not. > I thought you were trying to discourage > multiple Pyramid applications in the same process, and that Pyramid > was intended to run as one extensible application rather than multiple > applications side by site. Nah. There's no logical binary distinction there. Currently you can do it either way, or both. There'd be no reason to not have globals (except for maybe some idea of cleanliness) if you didn't want to make it possible to run more than one application per process. I'm not suggesting it's a "99%" use case, but for what it's worth, my company already uses it like this in production to save RAM where we have to support multiple (small) applications. - 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.
