Re: Best place for code that processes stuff from settings.py once (for logging implementation)

On Oct 15, 8:21 am, Ivan Sagalaev wrote: > Is it really the case that we want to log everything? I believe that > logging after initialization is enough. And for my example of a logging That may be true if you're a Django user, but for a Django developer working on

Re: Best place for code that processes stuff from settings.py once (for logging implementation)

Benjamin Slavin wrote: > * Logging may need to come even earlier. If you truly want to log > everything, you'll want to run that code first. Is it really the case that we want to log everything? I believe that logging after initialization is enough. And for my example of a logging handler

Re: Best place for code that processes stuff from settings.py once (for logging implementation)

On Oct 13, 3:12 pm, Benjamin Slavin wrote: > It looks like I may actually be able to put a bit of time toward a new > implementation for this, so I'll keep the list posted. As I said, great! But I thought I would have a go, too. Here's what I did: changed Django in

Re: Best place for code that processes stuff from settings.py once (for logging implementation)

On Oct 13, 3:12 pm, Benjamin Slavin wrote: > On Tue, Oct 13, 2009 at 2:17 AM, Vinay Sajip wrote: > > I know it was sloppy of me to call it "INSTALLED_APPS loading" as that > > happens in db/models/loading.py - I thought it would be clear from

Re: Best place for code that processes stuff from settings.py once (for logging implementation)

On Tue, Oct 13, 2009 at 2:17 AM, Vinay Sajip wrote: > I know it was sloppy of me to call it "INSTALLED_APPS loading" as that > happens in db/models/loading.py - I thought it would be clear from my > saying I was talking about calling from Settings.__init__(). Ok... I

Re: Best place for code that processes stuff from settings.py once (for logging implementation)

On Oct 13, 3:10 am, Benjamin Slavin wrote: > There really is no such thing as "INSTALLED_APPS loading".  I think > you mean "model loading"... if so, it's not quite so simple. Maybe > there's a way to make this approach work, but it's at least not as > easy as "let's

Re: Best place for code that processes stuff from settings.py once (for logging implementation)

> Maybe I'm oversimplifying this - and I'm sure if you'll tell me if I > am ;-) - but how about the following: add a setting called e.g. > SETUP_CALLBACKS  (or whatever name you prefer) which will be an > iterable (say, tuple) of callables which are called from > Settings.__init__ in the same way

Re: Best place for code that processes stuff from settings.py once (for logging implementation)

On Oct 12, 5:04 pm, Simon Willison wrote: > On Oct 12, 9:03 am, Benjamin Slavin wrote: > > > That means: I'm strongly in favor of any hook to allow code to be run > > before the Django environment is setup, and I'm not tied to any > >

Re: Best place for code that processes stuff from settings.py once (for logging implementation)

On Mon, Oct 12, 2009 at 12:09 PM, Jeremy Dunck wrote: > Also, I bet Marty knows this area well from his book work. Actually, I didn't research much on the initialization process as a whole, if there indeed is such a beast. I started with what happens when Python actually

Re: Best place for code that processes stuff from settings.py once (for logging implementation)

On Oct 12, 2009, at 11:04 AM, Simon Willison wrote: > > On Oct 12, 9:03 am, Benjamin Slavin wrote: >> That means: I'm strongly in favor of any hook to allow code to be run >> before the Django environment is setup, and I'm not tied to

Re: Best place for code that processes stuff from settings.py once (for logging implementation)

On Oct 11, 2:32 am, Simon Willison wrote: > Is there a straight forward solution to this that I've been missing, > or is it an ongoing problem? If it's a problem, can we fix it? What > makes it so difficult to fix (I'm going to guess there's no easy > solution, or we

Best place for code that processes stuff from settings.py once (for logging implementation)

I've got to the point in the logging implementation where I want to add support for logging related settings in settings.py. The current idea (suggested by Ivan Sagalaev) is to allow for a standard Django-style setting that look something like this: LOGGING = { 'django.db.sql': {