On Jun 17, 10: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". > > Matt.
Hi, Just noting that another "filtering" functionality has recently been added to trunk [1]. It is a different kind of filtering than what's being discussed here -- it is to filter out sensitive information from error reports when they're being produced. Maybe the naming of one of those functionalities might need to be reconsidered in order to avoid confusion in the docs and APIs. I'm not sure. Just thought I'd point it out ;) (By the way, "production" is a common generic term used for when DEBUG is False) Julien [1] https://docs.djangoproject.com/en/dev/howto/error-reporting/#filtering-error-reports -- 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.
