[Django] #33179: Show helpful error message when first argument to shortcuts.render is not request
Django
request
-----------------------------------------+--------------------------
Reporter: Joel Sleppy | Owner: nobody
Type: New feature | Status: assigned
Component: Uncategorized | Version: dev
Severity: Normal | Keywords:
Triage Stage: Unreviewed | Has patch: 1
Needs documentation: 0 | Needs tests: 0
Patch needs improvement: 0 | Easy pickings: 0
UI/UX: 0 |
-----------------------------------------+--------------------------
This is one of a class of changes I'm interested in making, so please also
comment on if developer experience/error message improvements like this
are wanted in general.
I recently started a new Django project and got frustrated at tiny
mistakes I made that were difficult to find because of opaque error
messages.
Currently, writing this:
{{{
#!python
def render_view_missing_request(request):
return render('shortcuts/render_test.html')
}}}
leads to:
{{{
TypeError: render() missing 1 required positional argument:
'template_name'
}}}
which is very confusing because the developer ''did'' provide the template
name.
Writing another common variation:
{{{
#!python
def render_view_missing_request(request):
return render('shortcuts/render_test.html', {'foo': 'FOO'})
}}}
leads to:
{{{
TypeError: join() argument must be str or bytes, not 'dict'
}}}
which is easier to figure out given the stack trace, but still unhelpful
to a newcomer.
--
Ticket URL: <https://code.djangoproject.com/ticket/33179>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
Django
request
Reporter: Joel Sleppy | Owner: Joel Sleppy
Type: New feature | Status: assigned
Component: Uncategorized | Version: dev
Keywords: | Triage Stage: Unreviewed
Has patch: 1 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
Changes (by Joel Sleppy):
* owner: nobody => Joel Sleppy
--
Ticket URL: <https://code.djangoproject.com/ticket/33179#comment:1>
Django
request
Reporter: Joel Sleppy | Owner: Joel Sleppy
Component: Uncategorized | Version: dev
Keywords: | Triage Stage: Unreviewed
Has patch: 1 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
Comment (by Joel Sleppy):
PR opened here https://github.com/django/django/pull/14961
--
Ticket URL: <https://code.djangoproject.com/ticket/33179#comment:2>
Django
request
Reporter: Joel Sleppy | Owner: Joel Sleppy
Component: Uncategorized | Version: dev
Keywords: | Triage Stage: Unreviewed
Has patch: 1 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
Description changed by Joel Sleppy:
Old description:
> This is one of a class of changes I'm interested in making, so please
> also comment on if developer experience/error message improvements like
> this are wanted in general.
>
> I recently started a new Django project and got frustrated at tiny
> mistakes I made that were difficult to find because of opaque error
> messages.
>
> Currently, writing this:
>
> {{{
> #!python
> def render_view_missing_request(request):
> return render('shortcuts/render_test.html')
> }}}
>
> leads to:
>
> {{{
> TypeError: render() missing 1 required positional argument:
> 'template_name'
> }}}
>
> which is very confusing because the developer ''did'' provide the
> template name.
>
> Writing another common variation:
>
> {{{
> #!python
> def render_view_missing_request(request):
> return render('shortcuts/render_test.html', {'foo': 'FOO'})
> }}}
>
> leads to:
>
> {{{
> TypeError: join() argument must be str or bytes, not 'dict'
> }}}
>
> which is easier to figure out given the stack trace, but still unhelpful
> to a newcomer.
New description:
This is one of a class of changes I'm interested in making, so please also
comment on if developer experience/error message improvements like this
are wanted in general.
I recently started a new Django project and got frustrated at tiny
mistakes I made that were difficult to find because of opaque error
messages.
Currently, writing this:
{{{
#!python
def render_view_missing_request(request):
return render('shortcuts/render_test.html')
}}}
leads to:
{{{
TypeError: render() missing 1 required positional argument:
'template_name'
}}}
which is very confusing because the developer ''did'' provide the template
name.
Writing another common variation:
{{{
#!python
def render_view_missing_request(request):
return render('shortcuts/render_test.html', {'foo': 'FOO'})
}}}
leads to:
{{{
TypeError: join() argument must be str or bytes, not 'dict'
}}}
which is easier to figure out given the stack trace, but still unhelpful
to a newcomer.
I propose inspecting the first argument's class name to return a message
like this:
{{{
#!python
"First argument to render() must be an HttpRequest, not 'str'."
}}}
Similar type inspection is done in other shortcut functions such as
`get_object_or_404`.
--
--
Ticket URL: <https://code.djangoproject.com/ticket/33179#comment:3>
Django
request
Reporter: Joel Sleppy | Owner: Joel Sleppy
Component: Uncategorized | Version: dev
Keywords: | Triage Stage: Unreviewed
Has patch: 1 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
Description changed by Joel Sleppy:
Old description:
> This is one of a class of changes I'm interested in making, so please
> also comment on if developer experience/error message improvements like
> this are wanted in general.
>
> I recently started a new Django project and got frustrated at tiny
> mistakes I made that were difficult to find because of opaque error
> messages.
>
> Currently, writing this:
>
> {{{
> #!python
> def render_view_missing_request(request):
> return render('shortcuts/render_test.html')
> }}}
>
> leads to:
>
> {{{
> TypeError: render() missing 1 required positional argument:
> 'template_name'
> }}}
>
> which is very confusing because the developer ''did'' provide the
> template name.
>
> Writing another common variation:
>
> {{{
> #!python
> def render_view_missing_request(request):
> return render('shortcuts/render_test.html', {'foo': 'FOO'})
> }}}
>
> leads to:
>
> {{{
> TypeError: join() argument must be str or bytes, not 'dict'
> }}}
>
> which is easier to figure out given the stack trace, but still unhelpful
> to a newcomer.
>
> I propose inspecting the first argument's class name to return a message
> like this:
>
> {{{
> #!python
> "First argument to render() must be an HttpRequest, not 'str'."
> }}}
>
> Similar type inspection is done in other shortcut functions such as
> `get_object_or_404`.
New description:
This is one of a class of changes I'm interested in making, so please also
comment on if developer experience/error message improvements like this
are wanted in general.
I recently started a new Django project and got frustrated at tiny
mistakes I made that were difficult to find because of opaque error
messages.
Currently, writing this:
{{{
#!python
def render_view_missing_request(request):
return render('shortcuts/render_test.html')
}}}
leads to:
{{{
TypeError: render() missing 1 required positional argument:
'template_name'
}}}
which is very confusing because the developer ''did'' provide the template
name, but nothing can be done about this as far as I know without changing
the function signature. Please let me know if there's a way to handle
this case nicely, though.
Writing another common variation:
{{{
#!python
def render_view_missing_request(request):
return render('shortcuts/render_test.html', {'foo': 'FOO'})
}}}
leads to:
{{{
TypeError: join() argument must be str or bytes, not 'dict'
}}}
which is easier to figure out given the stack trace, but still unhelpful
to a newcomer.
I propose inspecting the first argument's class name to return a message
like this:
{{{
#!python
"First argument to render() must be an HttpRequest, not 'str'."
}}}
Similar type inspection is done in other shortcut functions such as
`get_object_or_404`.
--
--
Ticket URL: <https://code.djangoproject.com/ticket/33179#comment:4>
Django
request
Reporter: Joel Sleppy | Owner: Joel
Cleanup/optimization | Status: closed
Component: HTTP handling | Version: dev
Severity: Normal | Resolution: wontfix
Keywords: | Triage Stage:
| Unreviewed
Has patch: 1 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
Changes (by Tim Graham):
* status: assigned => closed
* resolution: => wontfix
* component: Uncategorized => HTTP handling
* type: New feature => Cleanup/optimization
Comment:
While this sort of check can be useful, we have to be judicious. Type
checking prevents duck typing and also imposes a performance penalty. In
this case, I don't think the ease of debugging the usage mistakes
outweighs the drawback of an extra `isinstance` check on every request.
You can write to the DevelopersMailingList if you want to discuss the idea
with a wider audience.
--
Ticket URL: <https://code.djangoproject.com/ticket/33179#comment:5>