Hi Fraser, > > (a) Setting NOTSET on the root logger will cause absolutely everything > > to go through the logging system - this could be unnecessary overhead as > > well as being too much information. > > My reason for doing this was indeed to capture as much information as > possible and then give the user the ability to filter the messages > afterwards. I guess if there are lots of things logged in a single > request then this could get unmanageable.
I would say it is better to use the logging package's mechanisms for filtering, as it will mean both less run-time overhead and less work for you. It also allows for other logging sinks than your middleware (e.g. logging to file) and logging works much as in any other application, with no magic. > > (d) It's probably better to put logging configuration in settings.py; > > Moving the level configuration into settings.py is probably a good > idea, but I think it would be good to find a balance between ease of > getting the logging facility up and running and level of control for > more advanced users. > > Having the handler registered with the root logger by default means > things should just work with minimal configuration. If someone didn't > want this configuration, they could always use removeHandler to > unregister it from the root logger. > > What do people think? I think where you presently do the initialization (in middleware.py), you can check to see if the root logger has any handlers. If not, go ahead and add your handler as you do presently. Otherwise, assume logging has been configured in settings.py and don't do any configuration. This allows both novice users and advanced users to do the least amount of work: novice users do nothing in settings.py, and advanced users configure logging as they would do anyway. > > Also, you could consider using thread locals to hold the list of > > records, as this usage seems what they were designed for. > > I agree that thread locals would probably be ideal, but it looks like > threading.local was only introduced in Python 2.4. To stay aligned > with Django, it should really be 2.3 compatible. > Fair point - I'd forgotten that threading.local arrived with 2.4. Regards, Vinay --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~----------~----~----~----~------~----~------~--~---
