TEMPLATE_DEBUG / TemplateSyntaxError handling doesn't play nice with Jinja2

[miracle2k]

Django's error 500 page code in views/debug.py 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.

[miracle2k]

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

[Luke Plant]

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.

[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.

[Malcolm Tredinnick]

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.

[Armin Ronacher]

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

[Russell Keith-Magee]

Reopening following ​this thread on django dev.

[jkocherhans]

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

[Jacob]

Milestone 1.2 deleted