unittest.skip isn't a Mixin, it turns the class into an exception and raises it.
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. 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. > > > > > > -- > > "Bureaucrat Conrad, you are technically correct -- the best kind of > > correct." > > > > -- > > 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%2bunsubscr...@googlegroups.com). > > For more options, visit this group at > > http://groups.google.com/group/django-developers?hl=en. > > > > 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 > > -- > "I disapprove of what you say, but I will defend to the death your right to > say it." -- Evelyn Beatrice Hall (summarizing Voltaire) > "The people's good is the highest law." -- Cicero > > -- > 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.
