Re: [Django] #35083: Make django.utils.decorators.method_decorator work with async functions.
Django
------------------------------+------------------------------------
Reporter: Drew Winstel | Owner: nobody
Type: New feature | Status: new
Component: Utilities | Version: 5.0
Severity: Normal | Resolution:
Keywords: async | Triage Stage: Accepted
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
------------------------------+------------------------------------
Comment (by Drew Winstel):
That makes sense. Thanks, Natalia!
--
Ticket URL: <https://code.djangoproject.com/ticket/35083#comment:2>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
Django
------------------------------+------------------------------------
Reporter: Drew Winstel | Owner: nobody
Type: New feature | Status: new
Component: Utilities | Version: 5.0
Severity: Normal | Resolution:
Keywords: async | Triage Stage: Accepted
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
------------------------------+------------------------------------
Comment (by Carlton Gibson):
This ticket seems correct (`method_decorator` should work with `async def`
methods).
Out of interest though, `View` standardly has a sync `dispatch`, which
you've overridden here:
{{{
class View1(View):
@method_decorator(ensure_csrf_cookie)
async def dispatch(
self, request: HttpRequest, *args: Any, **kwargs: Any
) -> HttpResponse:
return await super().dispatch(request, *args, **kwargs)
}}}
... so would `method_decorator` work already for the ''usual cases'',
decorating `dispatch`? 🤔
Likely off-topic but just for future context, Drew could you maybe briefly
say how it comes up — I guess the Strawberry base class is `async def` all
the way... or ... 🤔?
Thanks.
--
Ticket URL: <https://code.djangoproject.com/ticket/35083#comment:3>
Django
------------------------------+------------------------------------
Reporter: Drew Winstel | Owner: nobody
Type: New feature | Status: new
Component: Utilities | Version: 5.0
Severity: Normal | Resolution:
Keywords: async | Triage Stage: Accepted
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
------------------------------+------------------------------------
Comment (by Drew Winstel):
> Out of interest though, View standardly has a sync dispatch, which
you've overridden here:
Right, that's because strawberry's `dispatch()` is overridden as well:
https://github.com/strawberry-
graphql/strawberry/blob/main/strawberry/django/views.py#L266-L277
> Likely off-topic but just for future context, Drew could you maybe
briefly say how it comes up — I guess the Strawberry base class is async
def all the way... or ... 🤔?
It does inherit from `django.views.generic.View`, but `dispatch()` is a
clean break from the generic view's version.
Strawberry's view includes the `@csrf_exempt()` decorator, but we (at my
day job) need `@ensure_csrf_cookie()` applied to that view because of
weird node.js things that I don't even pretend to understand. :D
--
Ticket URL: <https://code.djangoproject.com/ticket/35083#comment:4>
Django
------------------------------+------------------------------------
Reporter: Drew Winstel | Owner: nobody
Type: New feature | Status: new
Component: Utilities | Version: 5.0
Severity: Normal | Resolution:
Keywords: async | Triage Stage: Accepted
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
------------------------------+------------------------------------
@Drew @Carlton is there anything we can do better in the Strawberry Django
View? Happy to make changes there 😊
--
Ticket URL: <https://code.djangoproject.com/ticket/35083#comment:5>
Django
------------------------------+------------------------------------
Reporter: Drew Winstel | Owner: nobody
Type: New feature | Status: new
Component: Utilities | Version: 5.0
Severity: Normal | Resolution:
Keywords: async | Triage Stage: Accepted
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
------------------------------+------------------------------------
@Patrick — I don't think you need to. There's no reason why you can't
reimplement `dispatch`. (Of course if you can get by without doing so,
that's less code, but I don't think it's an issue per se, and this is
still an improvement we can make in Django.)
--
Ticket URL: <https://code.djangoproject.com/ticket/35083#comment:6>
Django
Reporter: Drew Winstel | Owner: Gaurav sah
Type: New feature | Status: assigned
Component: Utilities | Version: 5.0
Severity: Normal | Resolution:
Keywords: async | Triage Stage: Accepted
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
Changes (by Gaurav sah):
* owner: nobody => Gaurav sah
* status: new => assigned
--
Ticket URL: <https://code.djangoproject.com/ticket/35083#comment:7>
Django
Reporter: Drew Winstel | Owner: (none)
Type: New feature | Status: new
Severity: Normal | Resolution:
Keywords: async | Triage Stage: Accepted
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
------------------------------+------------------------------------
* owner: Gaurav sah => (none)
* status: assigned => new
--
Ticket URL: <https://code.djangoproject.com/ticket/35083#comment:8>