On 17 February 2012 20:22, Carl Meyer <c...@oddbird.net> wrote: > >> The second is class_view_decorator, to apply classic view decorators >> to the newer class-based views: >> >> @class_view_decorator(never_cache) >> @class_view_decorator(login_required, login_url='/my-login') >> @class_view_decorator(permission_required, 'thing.change_thing') >> class MyView(View): ... > > Unfortunately, class decorators that create and return a dynamic > subclass cause infinite recursion if super() is used in a method of the > decorated class, because the name given as the first argument to super() > will actually refer to the subclass at runtime. This problem, and > alternative options, were discussed extensively in a thread here a few > months ago. >
Just for reference, the ticket to track this is #14512 [1] - see the original thread, the thread about copying instead of subclassing and Jacob's proposal to unify it all. Here [2] you can find a testcase that demonstrates what Carl described. I can only add that after over a year of using the version which modifies the class in-place, my team never had trouble with that. The super() problem actually makes a great Python puzzle so it's easy to remember the dangers after solving it ;) [1]: https://code.djangoproject.com/ticket/14512 [2]: https://github.com/lqc/django/blob/cbvdecoration_ticket14512/tests/regressiontests/utils/decorators.py#L120 -- Łukasz Rekucki -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
