On 16 September 2011 10:17, Roald de Vries <downa...@gmail.com> wrote: > On Sep 16, 2011, at 12:11 AM, Łukasz Rekucki wrote: >> >> As the ticket creator I feel obligated to reply :) > > Me (as the poster of the latest patch) too :)
Nice to meet you. > >> Thinking about it now, it does look kinda ugly. It's mainly because I >> was focus on how to reuse existing decorators in CBV context. It >> shouldn't be to hard to make the "view_decorator" a meta-decorator >> (or a factory function as you call it) that turns login_required to >> something that is both a class and function decorator. Methods are >> still out-of-bounds for non-runtime introspection, but after almost 1 >> year of using CBV, I never needed to decorate a method. >> >> I would like to also comment on the new approach in that ticket. >> Making a shallow copy of a class is *MAGIC* to me. It breaks the basic >> invariant "issubsclass(decorator(A), A) == True". This is important if >> you're planing to use this as "B = decorator()(A)" (and you are, >> 'cause the whole point of not modifying the original class is to allow >> safely doing this), as you quickly end up with weird alternate >> hierarchies. So, please don't do that :) > > I agree that in an ideal world we'd have a better solution. On the other > hand, the cbv-decorator using inheritance just didn't work, and the one > using shallow copies does (if you don't use B=decorator()(A), indeed). The one that just alters the given class also works, has no magic and has the same limitation - dont' do "B = decorator(A)". Honestly, I never needed that, but I understand some people might. Also note, that the "super() problem" is fixed in Python 3, where super() determines the base class from the call frame instead of referencing a global variable. > > If this doesn't exist, then the view_decorator still has a right to live. > > So what would have to be created is a meta-decorator universal_decorator, > replacing or using view_decorator, such that > universal_decorator(login_required) is the actual universal decorator. This > would be applied to all django-decorators, but I think it would be good to > also allow applying universal_decorator to an already universal decorator, > such that: > > # after this... > login_required = universal_decorator(login_required) > # ... this will hold > assert login_required == universal_decorator(login_required) > > +1 -- Ł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.
