Misleading message 'super object has no attribute __getattr__' on AttributError during SimpleTemplateResponse.render

[Ivan Sagalaev]

Consider this code:

from django.template import Template
from django.template.response import SimpleTemplateResponse

class A(object):
    def __unicode__(self):
        return None.something

def index(request):
    return SimpleTemplateResponse(Template('{{ var }}'), {'var': A()})

This code emulates a situation of any AttributeError raised during initial template rendering from within SimpleTemplateReponse.render. The real error "NoneType object has no attribute something" is masked by a very weird-looking "super object has no attribute getattr". The traceback also points inside SimpleTemplateResponse.getattr which has no relation whatsoever to the real point of error.

[Ivan Sagalaev]

Patch

[Ivan Sagalaev]

It looks like the error is caused by an AttributeError raised while accessing property SimpleTemplateReponse.rendered_content from with super(...).__getattr__ call. In this case any internal AttributeError is indistinguishable from the one of absence of the __getattr__ itself.

I've reimplemented the code using __getattribute__ that doesn't introduce this side-effect.

I'm in doubts about tests… Should we really test such a strange corner case and if yes, how? It seems that the only way is to check for certain words in an exception message which seems fragile.

[Luke Plant]

There is a double problem here - the code in question should use getattr on the super object, not __getattr__ which doesn't exist.

However, I'm proposing we remove it altogether - the point of the code is to aid debugging in an obscure case, but actually massively hinders debugging in a (probably) vastly more common case. See ​https://groups.google.com/forum/#!topic/django-developers/Vmyi0b6VJgo

I imagine your approach is fine, but I'd prefer not to implement __getattribute__ unless we really need it, and it seems overkill here.

[Ivan Sagalaev]

(I posted to django-dev@ but it stuck in moderation queue for some reason.)

I completely agree. My natural approach was to just fix the code without changing semantics but may be I was overly cautious :-). And your point on using getattr() is correct but it didn't help masking of the original exception so I went the __getattribute__ way.

[Luke Plant]

In [16917]:

(The changeset message doesn't reference this ticket)