I just got my wisdom teeth removed so i'm not exactly feeling the greatest, however I committed what I've done so far and pushed to my copy of django on github.
The goal is to provide a Mixin for class based views, a decorator for class based views, a decorator for methods, and a decorator for functions, all from the same codebase. Currently I have the decorator for classes working, and the mixin working. I have the places where the other 2 will go but from a combination of not being very good at decorators, and not feeling well I haven't finished it yet. Anyways here's what I've gotten so far: https://github.com/dstufft/django/compare/master...universal-mixin-decorators On Wednesday, September 21, 2011 at 8:26 AM, Roald de Vries wrote: > Hi all, > > Haven't seen a comment on this topic for a few days, so was wondering if a > core dev can make a design decision yet. I have some spare time in the > remainder of this week, so if the (universal) decorator-approach is chosen, I > should be able to finish it shortly (the mixin-approach is a bit harder to > estimate). > > Cheers, Roald > > > On Sep 17, 2011, at 4:32 AM, Alex Gaynor wrote: > > On Fri, Sep 16, 2011 at 10:27 PM, Donald Stufft <donald.stu...@gmail.com > > (mailto:donald.stu...@gmail.com)> wrote: > > > unittest.skip isn't a Mixin, it turns the class into an exception and > > > raises it. > > > > > > > It doesn't *turn* a class into anything, it simply returns a function, > > instead of a new class, and the function raises SkipTest, the point wasn't > > the implementation detail, but rather the syntax and pattern at work. > > > > > django.test.utils.override_settings is a mixin and it's terrible, it > > > dynamically creates a new subclass, and overrides 2 methods. It's magic > > > and more complex then need be. > > > > > > > > > a) it's not a mixin > > b) yes, it creates subclasses, because the alternative is mutating the > > original class, which isn't how people generally expect decorators to work, > > we expect them to be syntactic sugar for: > > > > A = wrap(*args)(A) > > > > such that we can also do > > > > B = wrap(*args)(A) > > > > and have two classes (or functions). > > > > c) I'm not sure how it's magic, but certainly if it's too complex we'd take > > patches to simplify the implementation. > > > > > > > > On Friday, September 16, 2011 at 9:50 PM, Alex Gaynor wrote: > > > > > > > > > > > > > > > > > > > > > On Fri, Sep 16, 2011 at 9:47 PM, James Bennett <ubernost...@gmail.com > > > > (mailto:ubernost...@gmail.com)> wrote: > > > > > We have the following constraints: > > > > > > > > > > 1. Django supports class-based views. > > > > > > > > > > 2. Django supports function-based views (ultimately these are the > > > > > same > > > > > thing, which is that Django supports anything as a 'view' so long as > > > > > it's callable, accepts an HttpRequest as its first positional > > > > > argument > > > > > when being called and either returns an HttpResponse or raises an > > > > > exception). > > > > > > > > > > 3. The natural way to add processing in/around a class is subclassing > > > > > and either overriding or mixing in. > > > > > > > > > > 4. The natural way to add processing in/around around a function is > > > > > decorating. > > > > > > > > > > Any solution to this needs to address those constraints, and allow > > > > > code to look and feel natural. > > > > > > > > > > Based on that, some arrangement which allows the same basic logic to > > > > > exist in a "mixin" (I dislike that word) for classes and a decorator > > > > > for functions seems most appropriate, even if it does mean having two > > > > > ways to do things -- that's a distinction I think we can live with, > > > > > as > > > > > people will appreciate that it doesn't result in strange-looking > > > > > code. > > > > > > > > I agree with all your points, except #3, I think it's an over > > > > simplification. There's another way to change a class: class > > > > decorators. And there's ample precedent for their use in such a manner, > > > > unittest's skip decorators, our own decorators for swapping settings > > > > during testing, etc. > > > > > > > > Alex > > Alex > > -- > 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 > (mailto:django-developers@googlegroups.com). > To unsubscribe from this group, send email to > django-developers+unsubscr...@googlegroups.com > (mailto:django-developers+unsubscr...@googlegroups.com). > For more options, visit this group at > http://groups.google.com/group/django-developers?hl=en. -- 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.
