#31949: Allow builtin view decorators to be applied directly to async views.
--------------------------------+-------------------------------------
Reporter: Michael Galler | Owner: Ben Lomax
Type: New feature | Status: assigned
Component: Core (Other) | Version: 3.1
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 Carlton Gibson):
* has_patch: 1 => 0
Comment:
Hi Ben — Happy New Year!
I've looked again at the PR, both before and after Christmas. In summary,
I
think we should address this ticket in a series of smaller PRs, rather
than
trying to do them all in one big go.
As I see it, there are two groups of issue with the current approach:
* The bulk edit means the code in quite a few time not sensitive enough to
the individual decorator. Looking at them, couldn't we write this one that
way, or that one this way?, is the thought. (I left some more specific
comments on the PR itself.) If we address them one-by-one (or in small
related groups, likely) we can write the best code for each case. There
are repeated patterns and opportunities for code-reuse, but I think
extracting them as we go is going to work better than trying to determine
them in advance.
* Related, the tests for each decorator need to live with the existing
related tests, not be centralised in one place. Five years hence, when we
come to work on the login_required logic, say, we need to be able to open
the relevants tests and see them all together. Having to track down a
separate set of tests in another part of the test suite entirely would be
a maintenance headache. If we address the decorators individually this
tendency won't be there.
I hope both of those points make sense?
I think the general idea is correct thought, and I don't see anything to
stop
us being able to process smaller `Refs #31949 -- ...` PRs relatively
quickly.
I think it would be good to address the whole list of built-in decorators
within a single release cycle though. As such I'm going to put this on my
target list for 5.0. I'll pick it up mid-cycle to help make sure we can
get it over the line.
Thanks again for your patience and input. I know it's frustrating when it
takes a while to get it lined up right.
--
Ticket URL: <https://code.djangoproject.com/ticket/31949#comment:27>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
--
You received this message because you are subscribed to the Google Groups
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-updates/0107018581177dad-fd06e8ca-9b55-46de-8ba8-4cf8f23564e5-000000%40eu-central-1.amazonses.com.
