Revisiting `django.template.context_processors.debug`

Django Internals
1

Reflecting on the django.template.context_processors.debug and am curious how the community uses it.

TL;DR: debug in the template context is not the same as settings.DEBUG. I find this confusing, and perhaps there’s an opportunity to improve.

Outlined thoughts in the issue tracker, but probably should have started out here on the forum.

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

The purpose of the context process is to capture and expose SQL queries to the template, but only when DEBUG is True, and the current IP is in a safelist. It also exposes debug, but only when both those conditions are met. This is inconsistent with the term “debug” everywhere else in Django.

Could the context processor be renamed from debug to debug_sql for example?

In a perfect world, I’d like debug to mean settings.DEBUG, but changing this behaviour could have adverse consequences on projects.

Since it’s so trivial to define a context variable, I wonder if this is something left up to users to define.

Further, this context processor (and sql_queries) was implemented in one of Django’s first commits and has barely changed in 19 years. With today’s rich ecosystem and third party libs dedicated to profiling Django queries and performance, does it still make sense to provide this feature in the core framework.

Or, is it time to deprecate this context processor?

2

If there were to be a change made in this area, I could see removing it from the default context processors that are defined in the startproject template.

This would have no effect on any existing projects that could possibly be using it, and reduces its “visibility” or “prominence” for new projects being created - while maintaining its availability for those wanting to use it.

Its existance alone doesn’t prevent or prohibit a different context processor from being created or used to add a context variable named “debug” which mirrors the current setting. (You just wouldn’t be able to use the two of them together.) And as you point out, its maintenance load has been low, which implies that it’s not that big of an issue to keep it.

1 Like
3

@marcgibbons I agree this context processor is a bit weird. Requiring both the DEBUG setting and INTERNAL_IPS is a strange combination, since Django recommends DEBUG never be used in production anyway. The same logic was copied in django-debug-toolbar

INTERNAL_IPS is weird anyway. It probably doesn’t fit most projects these days, since fewer companies use an intranet. To activate django-debug-toolbar, and I guess the debug context processor, most need to add INTERNAL_IPS = ["127.0.0.1"], which is kind of nonsense since 127.0.0.1 is by definition internal.

I also that would be a sensible move.

1 Like
4

@KenWhitesell I really like the idea of gently transitioning it out of the default processors list.

@adamchainz To add to the weirdness / inconsistency, there’s also a {% debug %} template tag – it doesn’t consider INTERNAL_IPS.

And, agreed. INTERNAL_IPS might be worth revisiting. It’s been around forever.

It, along with the debug context variable, XViewMiddleware and the internal/external ternary for logging have been around forever:

5

Oh yeah… :exploding_head:

Oh wow, that is a super niche debugging aid. That can probably be deprecated with little concern. django-debug-toolbar probably fills that void for most people, or using the shell to call resolve()…

That’s this code?

Yeah, a bit weird to shout EXTERNAL on every email even when INTERNAL_IPS is not configured.

1 Like