[Django] #20745: {{ block.super }} silences/hides errors
Django
-------------------------------+--------------------
Reporter: robin | Owner: nobody
Type: Bug | Status: new
Component: Uncategorized | Version: 1.5
Severity: Normal | Keywords:
Triage Stage: Unreviewed | Has patch: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------+--------------------
Say I create '''myapp/admin.py''' which contains:
{{{
from django.contrib import admin
from myapp.models import MyModel
class MyModelAdmin(admin.ModelAdmin):
list_display = ('pk','abc')
def abc(self, user):
return 999+None
admin.site.register(MyModel, MyModelAdmin)
}}}
Then when you visit http://localhost:8000/admin/myapp/mymodel/ a
'''TypeError''' will raise because you cannot add 999 and None together.
This is the '''expected outcome'''.
However if I add '''templates/admin/myapp/mymodel/change_list.html'''
which contains:
{{{
{% extends "admin/change_list.html" %}
{% block content %}
{{ block.super }}
{% endblock %}
}}}
The '''TypeError will not appear''' and the page renders but without any
content, which is '''not the expected outcome'''.
This ticket seems similar to https://code.djangoproject.com/ticket/18169
--
Ticket URL: <https://code.djangoproject.com/ticket/20745>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
Django
---------------------------------+------------------------------------
Reporter: robin | Owner: nobody
Type: Bug | Status: new
Severity: Normal | Resolution:
Keywords: | Triage Stage: Accepted
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
Changes (by bmispelon):
* cc: bmispelon@… (added)
* needs_better_patch: => 0
* component: Uncategorized => Template system
* needs_tests: => 0
* needs_docs: => 0
* stage: Unreviewed => Accepted
Comment:
I made a small template tag and managed to reproduced the issue easily:
https://gist.github.com/bmispelon/6031523
Note that only `TypeError` seems to trigger the bug (I tested with
`KeyError` or `AttributeError` and they're both propagated correctly).
Digging a bit deeper, it seems this is a regression introduced by
4397c587a43ff9bfddd295d48d850676778c6e77.
--
Ticket URL: <https://code.djangoproject.com/ticket/20745#comment:1>
Django
---------------------------------+------------------------------------
Type: Bug | Status: closed
Component: Template system | Version: 1.5
Keywords: | Triage Stage: Accepted
Has patch: 0 | Needs documentation: 0
Easy pickings: 0 | UI/UX: 0
Changes (by anonymous):
* status: new => closed
* resolution: => fixed
Comment:
This actually works for me on trunk/master using bmispelon's gist, so it
should have been fixed in some point between 1.6 or 1.7. The only change i
did to the gist was using `__builtin__` instead of `builtins` for
python2.7 compatibility. I also tried raising a simple `TypeError`.
I'm marking this a closed, reopen if it's still happening.
--
Ticket URL: <https://code.djangoproject.com/ticket/20745#comment:2>
Django
---------------------------------+------------------------------------
Type: Bug | Status: new
Severity: Normal | Resolution:
Has patch: 0 | Needs documentation: 0
Easy pickings: 0 | UI/UX: 0
Changes (by aaugustin):
* status: closed => new
* resolution: fixed =>
Comment:
I'm not aware of any fixes in this area over the last week. Since it was
reproduced by a core dev and not reproduced by an anonymous I'd rather err
on the side of caution until we get a third opinion.
--
Ticket URL: <https://code.djangoproject.com/ticket/20745#comment:3>
Django
---------------------------------+------------------------------------
Type: Bug | Status: new
Severity: Normal | Resolution:
Keywords: | Triage Stage: Accepted
Has patch: 0 | Needs documentation: 0
Easy pickings: 0 | UI/UX: 0
Comment (by bmispelon):
Just tried it again and the issue is indeed still present.
Note that if you used the code from my earlier comment, the way to test if
the issue is still present is to try and render the `bar.html` template.
The correct behavior is that rendering this template should raise a
`TypeError`.
As of now (1.7, 1.6 or 1.5), no exception is raised, which is what the
original report describes.
I should have provided an actual testcase but I couldn't find how to
register a template library for a test.
--
Ticket URL: <https://code.djangoproject.com/ticket/20745#comment:4>
Django
---------------------------------+------------------------------------
Reporter: robin | Owner: nobody
Type: Bug | Status: new
Severity: Normal | Resolution:
Keywords: | Triage Stage: Accepted
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
---------------------------------+------------------------------------
Changes (by bmispelon):
* easy: 0 => 1
Comment:
After some digging, I think I'm starting to understand what's happening
here.
When django finds a callable element in a template (which `{{ block.super
}}` is, since it refers to a `BlockNode`'s `super` method), it attempts to
call it (without passing any argument), wrapping the calling in a
`try/except` and catching a `TypeError` (which happens when you call a
function/method without enough arguments).
In our case, a `TypeError` is raised from inside the function and
subsequently caught and silenced in the `except` clause.
Before 4397c587a43ff9bfddd295d48d850676778c6e77, any exception raised
while rendering a template would be wrapped in a `TemplateSyntaxError`.
This `TemplateSyntaxError` would then not be caught by the aforementionned
`except TypeError` clause and would bubble up.
Note that this would only happen with `settings.TEMPLATE_DEBUG = True`
(this discrepancy between the two values of `TEMPLATE_DEBUG` is actually
one of the reason why this change was introduced in the first place).
This is therefore a limitation of django's implementation, which stems
from the fact that it can't distinguish between a `TypeError` caused by
calling a function without enough arguments and a `TypeError` raised from
inside the function.
This limitation is noted in a comment in the code [1], but as far as I can
tell, it's not documented.
I'm leaving this ticket open but I see it as a documentation issue, unless
someone can come up with a clever way of side-stepping the problem but I'm
not sure there is one.
Since this details is somehow technical, I think a good place for it would
be this section: https://docs.djangoproject.com/en/1.5/ref/templates/api
/#variables-and-lookups
--
Ticket URL: <https://code.djangoproject.com/ticket/20745#comment:5>
Django
Reporter: robin | Owner: kedmiston
Type: Bug | Status: assigned
Component: Template system | Version: 1.5
Severity: Normal | Resolution:
Keywords: | Triage Stage: Accepted
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 1 | UI/UX: 0
Changes (by kedmiston):
* status: new => assigned
* owner: nobody => kedmiston
--
Ticket URL: <https://code.djangoproject.com/ticket/20745#comment:6>
Django
---------------------------------+------------------------------------
Type: Bug | Status: new
Component: Template system | Version: 1.5
Severity: Normal | Resolution:
Keywords: | Triage Stage: Accepted
Has patch: 0 | Needs documentation: 0
Easy pickings: 0 | UI/UX: 0
Changes (by kedmiston):
* owner: kedmiston =>
* status: assigned => new
* easy: 1 => 0
--
Ticket URL: <https://code.djangoproject.com/ticket/20745#comment:7>
Django
---------------------------------+------------------------------------
Reporter: robin | Owner:
Component: Template system | Version: 1.5
Severity: Normal | Resolution:
Keywords: | Triage Stage: Accepted
Has patch: 0 | Needs documentation: 0
Easy pickings: 0 | UI/UX: 0
Comment (by aaugustin):
We can distinguish between the two kinds of TypeError with
[http://docs.python.org/2/library/inspect#inspect.getcallargs
inspect.getcallargs].
We recently did it to fix a similar problem in
django/contrib/auth/__init__.py.
--
Ticket URL: <https://code.djangoproject.com/ticket/20745#comment:8>
Django
---------------------------------+------------------------------------
Reporter: robin | Owner:
Component: Template system | Version: 1.5
Severity: Normal | Resolution:
Keywords: | Triage Stage: Accepted
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
Changes (by bmispelon):
* has_patch: 0 => 1
Comment:
Interesting, I didn't know about `getcallargs`.
Here's a pull request that uses it to let `TypeError` bubble up when it
needs to:
https://github.com/django/django/pull/1602
--
Ticket URL: <https://code.djangoproject.com/ticket/20745#comment:9>
Django
Reporter: robin | Owner:
Type: Bug | Status: new
Component: Template system | Version: 1.5
Severity: Normal | Resolution:
Has patch: 1 | checkin
Needs tests: 0 | Needs documentation: 0
Easy pickings: 0 | Patch needs improvement: 0
| UI/UX: 0
-------------------------------------+-------------------------------------
Changes (by claudep):
* stage: Accepted => Ready for checkin
--
Ticket URL: <https://code.djangoproject.com/ticket/20745#comment:10>
Django
-------------------------------------+-------------------------------------
Type: Bug | Mispelon <bmispelon@…>
Component: Template system | Status: closed
Severity: Normal | Version: 1.5
Keywords: | Resolution: fixed
Has patch: 1 | Triage Stage: Ready for
Needs tests: 0 | checkin
Easy pickings: 0 | Needs documentation: 0
| Patch needs improvement: 0
| UI/UX: 0
-------------------------------------+-------------------------------------
* owner: => Baptiste Mispelon <bmispelon@…>
* status: new => closed
* resolution: => fixed
Comment:
In [changeset:"28a571348bca9c5a3c137e495e7d3c9349a5bd56"]:
{{{
#!CommitTicketReference repository=""
revision="28a571348bca9c5a3c137e495e7d3c9349a5bd56"
Fix #20745: Don't silence TypeError raised inside templates.
Thanks to robin for the report and claudep for the review.
}}}
--
Ticket URL: <https://code.djangoproject.com/ticket/20745#comment:11>
Django
-------------------------------------+-------------------------------------
Reporter: robin | Owner: Baptiste
Type: Bug | Mispelon <bmispelon@…>
Component: Template system | Status: closed
Severity: Normal | Version: 1.5
Keywords: | Resolution: fixed
Has patch: 1 | Triage Stage: Ready for
Needs tests: 0 | checkin
Easy pickings: 0 | Needs documentation: 0
| Patch needs improvement: 0
| UI/UX: 0
-------------------------------------+-------------------------------------
Comment (by pczerkas@…):
inspect.getcallargs is unavailable in Python 2.6
--
Ticket URL: <https://code.djangoproject.com/ticket/20745#comment:12>
Django
-------------------------------------+-------------------------------------
Reporter: robin | Owner: Baptiste
Type: Bug | Mispelon <bmispelon@…>
Severity: Normal | Version: 1.5
Keywords: | Resolution:
Needs tests: 0 | checkin
Easy pickings: 0 | Needs documentation: 0
| Patch needs improvement: 0
| UI/UX: 0
-------------------------------------+-------------------------------------
* status: closed => new
* resolution: fixed =>
--
Ticket URL: <https://code.djangoproject.com/ticket/20745#comment:13>
Django
-------------------------------------+-------------------------------------
Reporter: robin | Owner: Baptiste
Type: Bug | Mispelon <bmispelon@…>
Severity: Normal | Version: 1.5
Keywords: | Resolution: fixed
Has patch: 1 | Triage Stage: Ready for
Needs tests: 0 | checkin
Easy pickings: 0 | Needs documentation: 0
| Patch needs improvement: 0
| UI/UX: 0
-------------------------------------+-------------------------------------
* status: new => closed
* resolution: => fixed
Comment:
Hi,
The fix for this issue will be part of the 1.7 release which only supports
versions of Python above 2.7 [1] so this shouldn't be a problem.
[1] https://docs.djangoproject.com/en/dev/releases/1.7/#python-
compatibility
--
Ticket URL: <https://code.djangoproject.com/ticket/20745#comment:14>