Matt Bennett <matt@...> writes:
>
> > 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".
Reposting this, after Google swallowed my earlier response. Sorry if it
eventually turns up, making this a double post ...
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.
