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. Max. --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
