> This is a case for a custom Filter object [1]. The filter object > implementation would only be a few lines, to reject logging when DEBUG > is True, and can be attached to the admin email handler in the default > logging configuration. [2] This way the logging call can occur in all > code paths, and the admin email handler itself can remain > general-purpose, but the backwards-compatible behavior can be maintained. > > Matt, if you'd be willing to open a ticket for this, that'd be helpful. > If you feel like putting together a patch using the Filter approach, > that'd be even better ;-)
Here you are: https://code.djangoproject.com/ticket/16288 Since logging Filters are not specific to an individual logger or handler, I've just called it DebugFalseFilter. It's not a pretty name, but I couldn't come up with anything better - I decided it should convey what the filter allows through, but AFAIK there's no name for "not debug mode". Matt. -- 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 django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
