#35370: `request.context["debug"] is not settings.DEBUG` and the future of
`django.templates.context_processors.debug`:
-------------------------------------+-------------------------------------
Reporter: Marc | Owner: nobody
Gibbons |
Type: | Status: new
Cleanup/optimization |
Component: Template | Version: 5.0
system | Keywords: context processors,
Severity: Normal | internal ips, debug, template
Triage Stage: | Has patch: 0
Unreviewed |
Needs documentation: 0 | Needs tests: 0
Patch needs improvement: 0 | Easy pickings: 0
UI/UX: 0 |
-------------------------------------+-------------------------------------
I went down a rabbit hole recently with the
[https://docs.djangoproject.com/en/5.0/ref/templates/api/#django-template-
context-processors-debug: 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` when `settings.DEBUG = True` and
`context['debug'] is False` when `settings.DEBUG = False`
What I got:
- A context variable named `debug` is sometimes included, but only when
both `settings.DEBUG` is `True` and if `request.META['REMOTE_ADDR'] in
settings.INTERNAL_IPS`. In other words, `debug` exists and is true only
when your project has `DEBUG` 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
[https://github.com/django/django/commit/ed114e15106192b22ebb78ef5bf5bce72b419d13
#diff-
27135de559ecc2dc3f2548d6ce5cbc8495de0acf053c0b0d4d77e642b463f6beR16-R19:
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
in `DEBUG` – this is an outlier.
Ideally, `debug` in templates would have the same meaning as it does in
Python / the rest of the framework. Example:
{{{#!python
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.
--
Ticket URL: <https://code.djangoproject.com/ticket/35370>
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 unsubscribe from this group and stop receiving emails from it, send an email
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-updates/0107018ed520202f-9cabd18f-057c-4574-b218-881a52541708-000000%40eu-central-1.amazonses.com.
