#25269: Method decorator should accept a iterable of decorators
-------------------------------+--------------------------------------
Reporter: zauddelig | Owner: nobody
Type: Uncategorized | Status: new
Component: Utilities | Version: 1.8
Severity: Normal | Resolution:
Keywords: | Triage Stage: Unreviewed
Has patch: 1 | Needs documentation: 1
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------+--------------------------------------
Changes (by zauddelig):
* needs_docs: 0 => 1
Old description:
> Hello,
> The new method decorator allow to decorate a class directly. to augment
> its readability I would propose to let it accept an iterable of decorator
> functions.
>
> This could be useful because it's common to decorate views using
> redundant sets of decorators inside the same project or subproject, one
> could argue that the same result is attained creating a new decorator or
> a Mixin, yet an iterable, i. e. a tuple, seem to me more plastic and
> maintainable than a class or a function.
>
> This could be also useful if one intend to dynamically decorate
> dynamically created classes although this is most probably going to be
> useful in less than the 1% of the cases, so actually not significant.
>
> The proposal introduces a polymorphic behaviour to `method_decorator`
> which should now accept both function and iterables, so both the
> following examples should be valid:
>
> {{{
> decorators = (
> blacklist_ip,
> request_is_cool,
> login_required,
> )
>
> @method_decorator(decorators,"dispatch")
> class ProtectedView(View):
> # lot of meaningful code
> pass
>
> @method_decorator(login_required, "dispatch")
> class LessProtectedView(View):
> # lot of meaningful code
> pass
> }}}
New description:
Hello,
The new method decorator allow to decorate a class directly. to augment
its readability I would propose to let it accept an iterable of decorator
functions.
This could be useful because it's common to decorate views using redundant
sets of decorators inside the same project or subproject, one could argue
that the same result is attained creating a new decorator or a Mixin, yet
an iterable, i. e. a tuple, seem to me more plastic and maintainable
than a class or a function.
This could be also useful if one intend to dynamically decorate
dynamically created classes although this is most probably going to be
useful in less than the 1% of the cases, so actually not significant.
The proposal introduces a polymorphic behaviour to `method_decorator`
which should now accept both function and iterables, so both the following
examples should be valid:
{{{
decorators = (
blacklist_ip,
request_is_cool,
login_required,
)
@method_decorator(decorators,"dispatch")
class ProtectedView(View):
# lot of meaningful code
pass
@method_decorator(login_required, "dispatch")
class LessProtectedView(View):
# lot of meaningful code
pass
}}}
pull request: https://github.com/django/django/pull/5134
--
--
Ticket URL: <https://code.djangoproject.com/ticket/25269#comment:2>
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 django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-updates/067.06c99492b5b60962cdc0985e75bf42fc%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.
