#35370 closed Cleanup/optimization (wontfix)
`context["debug"] is not settings.DEBUG` and the future of `django.templates.context_processors.debug`:
Reported by: | Marc Gibbons | Owned by: | nobody |
---|---|---|---|
Component: | Template system | Version: | 5.0 |
Severity: | Normal | Keywords: | context processors, internal ips, debug, template |
Cc: | Marc Gibbons | Triage Stage: | Unreviewed |
Has patch: | no | Needs documentation: | no |
Needs tests: | no | Patch needs improvement: | no |
Easy pickings: | no | UI/UX: | no |
Description
I went down a rabbit hole recently with the django.templates.context_processors.debug context processor.
What I was looking for:
- A context variable called
debug
which is always present -
context['debug'] is True
whensettings.DEBUG = True
andcontext['debug'] is False
whensettings.DEBUG = False
What I got:
- A context variable named
debug
is sometimes included, but only when bothsettings.DEBUG
isTrue
and ifrequest.META['REMOTE_ADDR'] in settings.INTERNAL_IPS
. In other words,debug
exists and is true only when your project hasDEBUG
turned on AND you’re visiting from an allowed list of IPs. - A context variable named
sql_queries
lazily returns all SQL queries executed in the request for the purpose of profiling.
Some context:
- This context variable
debug
and its assignment is as old as Django. It appears in one of the first commits ever, and aside from being moved around over the years, has remained unchanged. - In no other area of Django is
INTERNAL_IPS
used to determine if you’re inDEBUG
– this is an outlier.
Ideally, debug
in templates would have the same meaning as it does in Python / the rest of the framework. Example:
def debug(request): return {"debug": settings.DEBUG}
Changing the context processor this way could be catastrophic.
Some thoughts:
debug
, and its evaluation (when present) in request context is confusing (at least to me).- This context processor has a variety of concerns: evaluating DEBUG, determining if you’re trusted on a network, and gathering SQL queries. Would it make sense to split it up accordingly?
- Or, given the risk security of changing how
debug
evaluates, could the entire context processor be marked for deprecation? Profiling SQL queries could be left to third party libraries like django-debug-toolbar. INTERNAL_IPS
might also be a candidate for deprecation.
Change History (3)
comment:1 by , 7 months ago
Summary: | `request.context["debug"] is not settings.DEBUG` and the future of `django.templates.context_processors.debug`: → `context["debug"] is not settings.DEBUG` and the future of `django.templates.context_processors.debug`: |
---|
comment:2 by , 7 months ago
Resolution: | → wontfix |
---|---|
Status: | new → closed |
comment:3 by , 7 months ago
Thanks, Tim. Pushed to the forum. https://forum.djangoproject.com/t/revisiting-django-template-context-processors-debug/30122
Note:
See TracTickets
for help on using tickets.
Hi Marc, it seems you summarized the documentation for the processor. I understand it doesn't meet your needs, but I don't see that as a reason to deprecate it. Use the DevelopersMailingList if you want to try to gather more opinions.