Opened 7 years ago

Closed 6 years ago

Last modified 4 years ago

#10216 closed (fixed)

TEMPLATE_DEBUG / TemplateSyntaxError handling doesn't play nice with Jinja2

Reported by: miracle2k Owned by: nobody
Component: Template system Version: master
Severity: Keywords:
Cc: Triage Stage: Accepted
Has patch: yes Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: UI/UX:


Django's error 500 page code in views/ probes exceptions for a source attribute, and if it exists, expects it to contain a 2-tuple pointing to the location where the error occurred.

Jinja2's TemplateSyntaxError also features a source attribute, but it instead contains the source string of the template.

As a result, when Jinja2 is used for templating and such an error occurs, Django breaks down while trying to build an error page for it. Instead, you get a simple WSGI strack trace for the new problem, rather than the actual template exception. The problem is this line:

origin, (start, end) = self.exc_value.source

I would argue that Django assumption that the existence of an attribute named source implies a specific protocol is flawed. It should either check for a specific class (though there are appear to be multiple), or at least make sure that it ignores values it can't handle.

Attachments (2)

10216.diff (1.2 KB) - added by miracle2k 7 years ago.
django-syntax-error-jinja.diff (1.3 KB) - added by Alex 6 years ago.

Download all attachments as: .zip

Change History (10)

Changed 7 years ago by miracle2k

comment:1 Changed 7 years ago by miracle2k

  • Has patch set
  • Needs documentation unset
  • Needs tests unset
  • Patch needs improvement unset

Patch checks that the first element of the tuple is Origin, which seems like is always the case.

comment:2 Changed 7 years ago by lukeplant

  • Resolution set to wontfix
  • Status changed from new to closed

It seems to me that the template debugging feature (enabled by TEMPLATE_DEBUG = True) inevitably has to assume that a certain template system is being used. The patch you propose introduces more assumptions about the template system being used, not less, and probably more fragile assumptions. I think you have to accept that if you have TEMPLATE_DEBUG = True but you are not using Django templates, things are not going to work unless you have been careful to maintain interface compatibility, which Jinja2 does not. Your patch could actually break things for someone else who was using a modified Django template system which did maintain interface compatibility (duck-typing style), but didn't use the 'Origin' class.

So I'm closing WONTFIX, unless a compelling solution is found. At some point you are simply going to have to make assumptions about the template system, or set TEMPLATE_DEBUG = False.

comment:3 Changed 7 years ago by miracle2k

I somehow didn't even think about TEMPLATE_DEBUG. You're right, it's functionality is pretty exclusively bound to Django's template system.

There is still a minor issue in that sometimes you may be forced to use both systems, e.g. when it comes to the admin or other contrib or 3rd party apps, and this basically means that you can't have the setting enabled for those cases. But that might just be something you have to live with.

comment:4 Changed 7 years ago by mtredinnick

Sounds like a bug in Jinja, if it's meant to inter-operate here. Django had the "source" attribute first, after all. :-)

There's certainly no "protocol flaw". Django expects a certain interface. If something else is trying to match that interface or be used in place of Django's templates, they have to do it propoerly. It's our protocol, after all. it's like saying the requirement of a "Host" header in HTTP is a protcol flaw; it's not -- it's part of the protocol/interface. Duck-typing operates by checking for behaviour/attributes, not types.

I agree with Luke's resolution. If there's some way to detect the Jinja behaviour and add a workaround for that, it might be interesting to look at, but it would be a hack and not particularly pleasant.

comment:5 Changed 6 years ago by mitsuhiko

Why not just check if the exc_value is an instance of django's TemplateSyntaxError?

comment:6 Changed 6 years ago by russellm

  • milestone set to 1.2
  • Resolution wontfix deleted
  • Status changed from closed to reopened
  • Triage Stage changed from Unreviewed to Accepted

Reopening following this thread on django dev.

Changed 6 years ago by Alex

comment:7 Changed 6 years ago by jkocherhans

  • Resolution set to fixed
  • Status changed from reopened to closed

(In [12586]) Fixed #10216. Only try to gather template exception info if the exception is a Django TemplateSyntaxError. Thanks, Alex Gaynor.

comment:8 Changed 4 years ago by jacob

  • milestone 1.2 deleted

Milestone 1.2 deleted

Note: See TracTickets for help on using tickets.
Back to Top