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

[Marc Gibbons]

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 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 ​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:

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.

[Tim Graham]

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.

[Marc Gibbons]

Thanks, Tim. Pushed to the forum. ​https://forum.djangoproject.com/t/revisiting-django-template-context-processors-debug/30122