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
> 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> 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.
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.
