Opened 14 years ago
Last modified 5 years ago
#14365 new New feature
Make template-rendering signals available also in DEBUG mode
Reported by: | Carl Meyer | Owned by: | Carl Meyer |
---|---|---|---|
Component: | Testing framework | Version: | dev |
Severity: | Normal | Keywords: | |
Cc: | Triage Stage: | Accepted | |
Has patch: | yes | Needs documentation: | yes |
Needs tests: | no | Patch needs improvement: | yes |
Easy pickings: | no | UI/UX: | no |
Description
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.
Attachments (2)
Change History (12)
comment:1 by , 14 years ago
Triage Stage: | Unreviewed → Accepted |
---|---|
Version: | 1.2 → SVN |
comment:2 by , 14 years ago
Has patch: | set |
---|---|
Owner: | changed from | to
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.
by , 14 years ago
Attachment: | 14365_r13962.diff added |
---|
by , 14 years ago
Attachment: | 14365_djangobench.txt added |
---|
comment:3 by , 14 years ago
Oh, the patch is also available at http://github.com/carljm/django/compare/master...ticket_14365
comment:4 by , 14 years ago
Needs documentation: | set |
---|
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...
comment:5 by , 14 years ago
Patch needs improvement: | set |
---|
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...
comment:6 by , 13 years ago
Severity: | → Normal |
---|---|
Type: | → New feature |
comment:9 by , 5 years ago
Resolution: | → wontfix |
---|---|
Status: | new → closed |
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.
comment:10 by , 5 years ago
Resolution: | wontfix |
---|---|
Status: | closed → new |
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.
Marking Accepted based on IRC approval-in-concept (depending on performance impact) from Russell and Jacob.