On Dec 19, 2007 4:31 AM, Max Ischenko <[EMAIL PROTECTED]> wrote: > > > > On 12/18/07, Mike Orr <[EMAIL PROTECTED]> wrote: > > I've found two rare cases for it. One was for a reference object > > that's built on application startup, which I could just have easily > > put into a module global. The other was for the SQLAlchemy engine, > > which also worked better as a module global instead. Oh, another time > > I thought 'g' would be a good place for thread-unsafe objects, but > > then found out it's shared between threads. So what good is it? > > A module global? > Are you kidding? May be my project is unique, but most of the stuff I put > into g depend on some configuration bits, most of which come from the .ini > file. I can't use module global since pylons.config is not available at > import time.
But it is available when Globals.__init__ is running. I either do it there or stuff it into config['pylons.g'] from load_environment. -- Mike Orr <[EMAIL PROTECTED]> --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "pylons-devel" group. To post to this group, send email to pylons-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/pylons-devel?hl=en -~----------~----~----~----~------~----~------~--~---
