Make template-rendering signals available also in DEBUG mode

[Carl Meyer]

Django's test setup monkeypatches the template renderer to send a signal every time a template is rendered. The test client handles this signal to provide template-rendered debugging information.

It would be useful to have access to this signal in DEBUG mode, not only in testing, so that the test Client can be used from the python shell without losing the template info, and so external tools like django-debug-toolbar can make use of it without having to monkeypatch.

The original reason for the current behavior was performance; signals used to be quite slow. This is no longer the case (and it should be possible to make the performance impact in production nothing more than a single DEBUG check at startup/init time). Nonetheless, any patch here should come with performance impact data.

[Carl Meyer]

Marking Accepted based on IRC approval-in-concept (depending on performance impact) from Russell and Jacob.

[Carl Meyer]

Here's my initial go at a patch. It bases the sending of the signal on the value of TEMPLATE_DEBUG, and setup_test_environment forces the sending of the signal regardless.

As you can see, this patch does a boolean if check on every template render. This is the simplest, most straightforward code, so I decided to try it first and check the performance impact. I added a template_render_simple benchmark to djangobench (available at ​http://github.com/carljm/djangobench/tree/template_render_simple) to focus on the render call itself and eliminate as much noise as possible. Results also attached: djangobench certainly isn't detecting any noticeable slowdown; half the time it seems to think it's faster, which suggests to me that any impact is so small as to be completely insignificant.

If someone can detect a statistically significant slowdown from this change, or suggest any alternative benchmarking methods that might detect one, I have ideas for how the boolean check could be done just once at import time. But all of these ideas would involve less readable and maintainable code, so I'm going to vote for the simple approach in the absence of any evidence of a performance issue.

[Carl Meyer]

Oh, the patch is also available at ​http://github.com/carljm/django/compare/master...ticket_14365

[Russell Keith-Magee]

Patch looks good, except for the absence of docs. We're adding a new public signal, and an API that would allow people to subclass (or monkeypatch) Template to turn on that signal.

Actually, that makes me wonder if Template should maybe take a 'enable signals' argument so you can turn on signals on a per-instance basis, rather than needing to subclass or monkeypatch...

[Carl Meyer]

Actually, on further review, this patch needs more work. I used a class attribute on Template to avoid a check every time a template is instantiated, but introducing an import-time settings dependency is not OK.

Given that there's already a TEMPLATE_DEBUG check in Template.init, I can probably piggyback on that with almost zero perf impact (I'll benchmark, of course), and having the API be via an arg to Template.init (defaulting to TEMPLATE_DEBUG) is nicer than a class attribute (which is basically a global). Just need to figure out how to allow the test system to force it to True...

[Aymeric Augustin]

Change UI/UX from NULL to False.

[Aymeric Augustin]

Change Easy pickings from NULL to False.

[Mariana Bedran Lesche]

The issue was opened 9 years ago and never revisited after the author realized the patch needed more work. It's flagged with the 1.2 version which is not supported anymore.

[Mariusz Felisiak]

7 years of silence doesn't mean that this ticket is not valid anymore (e.g. few days ago we closed 11 years old ticket). Ticket is targeted to master.