Sorry to keep it alive, but what about the ability to pass an iterator to
the method_decorator? It would be sightly similar to this:
def _wrapper(self, *args, **kwargs):
def bound_func(*args2, **kwargs2):
return func.__get__(self, type(self))(*args2, **kwargs2)
if hasattr(decorator, "__iter__"):
bound_func = reduce(lambda acc, dec: dec(acc), decorator,
bound_func)
else:
bound_func = decorator(bound_func)
# bound_func has the signature that 'decorator' expects i.e. no
# 'self' argument, but it is a closure over self so it can call
# 'func' correctly.
return bound_func(*args, **kwargs)
The discussion is about the usefulness of this I think.
On Friday, August 7, 2015 at 8:22:51 PM UTC+2, Fabrizio Messina wrote:
>
> Sorry did read the commit code now and the new *method_decorator* seems
> to solve most of the problem
>
> On Thursday, August 6, 2015 at 11:21:36 AM UTC, Fabrizio Messina wrote:
>>
>> Hello I would like to ask why the class based views documentation seems
>> so much ugly. Some developers probably are scared by these just because the
>> decoration is ugly, the documentation offers three ways:
>>
>> Decorate the *Klass().dispach()* method of the class, wrapping the
>> decorators in another decorator:
>>
>> @method_decorator(decorator_1)
>> def dispatch(request, *args, **kwargs):
>> pass
>>
>> Wrapping the *Klass.as_view()* resulting in an arguably ugly
>>
>> *:*
>>
>>
>> *decorator_1( decorator_2( .. ( .. decorator_n( Klass.as_view() ) .. ) ..
>> ))*In my opinion this is an issue because decoration is actually cool and
>> the
>> alternative is to use the much more dreadful Multiple Inheritance, that is
>> the documented third way.
>>
>>
>> I personally use reduce syntax:
>>
>> view = reduce(lambda x, f: f(x), (decorator_1, decorator_2, ..,
>> decorator_n), Klass.as_view())
>>
>> Probably there are better ways but still to me it seems to me that
>> something like this is more readable, easier to modify and less scary. To
>> me it has the pro that one could easily wrap common used decorators in a
>> single iterable.
>>
>
--
You received this message because you are subscribed to the Google Groups
"Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-developers/f6fca887-2d11-48fa-b529-1ed07f9845db%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
