#16288: Enabling 'django.request' logger when DEBUG is True
---------------------------------------+------------------------------
Reporter: mattbennett | Owner: nobody
Type: New feature | Status: new
Milestone: | Component: Core (Other)
Version: SVN | Severity: Normal
Resolution: | Keywords: logging
Triage Stage: Accepted | Has patch: 1
Needs documentation: 0 | Needs tests: 0
Patch needs improvement: 0 | Easy pickings: 0
UI/UX: 0 |
---------------------------------------+------------------------------
Comment (by carljm):
Replying to [comment:3 anonymous]:
> 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.
This is certainly more general, and adds some flexibility. My concern
about it is that it makes the settings check eager (at the time LOGGING is
defined) rather than lazy. I foresee this causing trouble for people who
commonly toggle their DEBUG value in an "import local_settings" near the
bottom of their settings.py, which, from what I've seen, is a common
pattern. Anyone who for any reason is modifying DEBUG after the definition
of LOGGING would need to be aware of this and explicitly switch the
"condition" argument in LOGGING as well; and they may well not be aware of
its use in LOGGING, especially if they just got the LOGGING config as part
of the default template settings.py from startproject. This could easily
cause someone to stop getting admin error emails in production, if they
leave the default "DEBUG = True" at the top of settings.py and tweak it to
False in a local_settings.py in production, for example. And it would be
quite confusing to sort out the cause.
So I think the current `DebugFalseFilter` is preferable to this proposal,
even though it is more specific and less flexible, unless there is a way
to modify this option to get the lazy behavior.
Which, now that I think of it, might be as simple as making `condition` a
callable and changing `not DEBUG` to `lambda: not DEBUG`, since closures
in Python follow later rebindings of a name in the same scope. Need to
test this out...
--
Ticket URL: <https://code.djangoproject.com/ticket/16288#comment:6>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
--
You received this message because you are subscribed to the Google Groups
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-updates?hl=en.
