[Django] #35370: `request.context["debug"] is not settings.DEBUG` and the future of `django.templates.context_processors.debug`:

[Django]

#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.