On Jun 17, 1:48 pm, Matt Bennett <m...@bennett.name> wrote: > > 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".
A more general solution would be something like this: class ConditionFilter(logging.Filter): def __init__(self, condition): self.condition = condition def filter(self, record): return self.condition which you can then use in the logging configuration using something like 'require_debug_false': { '()': 'django.utils.log.ConditionFilter', 'condition': not DEBUG, } This will allow the filter to be used in more places, e.g. you could use a more complex settings-time condition. Regards, Vinay Sajip -- 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.