id	summary	reporter	owner	description	type	status	component	version	severity	resolution	keywords	cc	stage	has_patch	needs_docs	needs_tests	needs_better_patch	easy	ui_ux
35370	"`context[""debug""] is not settings.DEBUG` and the future of `django.templates.context_processors.debug`:"	Marc Gibbons	nobody	"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.
"	Cleanup/optimization	closed	Template system	5.0	Normal	wontfix	context processors, internal ips, debug, template	Marc Gibbons	Unreviewed	0	0	0	0	0	0