Class based generic views in 1.3?

150 views
Skip to first unread message

Jari Pennanen

unread,
May 10, 2010, 5:39:54 PM5/10/10
to Django developers
I've been trying to figure out the state of class based generic views
without success. (Though syndication views seems to be class based now
at least.)

If I figured out correctly the class based generic views does not land
on 1.2, so I was wondering are they planned to 1.3? Those are rather
important after all...

--
You received this message because you are subscribed to the Google Groups "Django developers" group.
To post to this group, send email to django-d...@googlegroups.com.
To unsubscribe from this group, send email to django-develop...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.

Russell Keith-Magee

unread,
May 10, 2010, 8:37:54 PM5/10/10
to django-d...@googlegroups.com
On Tue, May 11, 2010 at 5:39 AM, Jari Pennanen <jari.p...@gmail.com> wrote:
> I've been trying to figure out the state of class based generic views
> without success. (Though syndication views seems to be class based now
> at least.)
>
> If I figured out correctly the class based generic views does not land
> on 1.2, so I was wondering are they planned to 1.3? Those are rather
> important after all...

No - class-based views didn't land in 1.2. This is one of those
features that everyone agrees is a good idea, but someone needs to
actually write the code. Jacob made the most recent attempt at an
implementation that I'm aware of [1], but as the changelog indicates,
he hasn't made any recent updates.

Syndication-based views became class-based because of the good work of
Ben Firshman. He worked up a very good patch, submitted it in time for
the feature freeze, bugged a couple of core developers for reviews,
and it was committed.

Are class-based views planned for 1.3? Well, we haven't done any
formal planning for 1.3 yet, but I'm going to guess that the 1.3 high
priority feature list will essentially be "the features that got
dropped from 1.2", so in all likelihood, yes. However, that doesn't
mean that they will definitely be in 1.3 - someone still needs to do
the implementation. If you really want class based generic views, be
like Ben and make it happen -- show us the code!.

[1] http://github.com/jacobian/django/tree/class-based-generic-views/django/views/generic2

Yours,
Russ Magee %-)

Jari Pennanen

unread,
May 11, 2010, 1:35:14 PM5/11/10
to Django developers

On 11 touko, 03:37, Russell Keith-Magee <russ...@keith-magee.com>
wrote:
Yes, well. I have been in slight assumption that the above code is the
one that will be merged. Though if it needs to be improved, I think
Jacobian could *list the problems in his implementation* so others can
try to improve on them, as he probably knows that code best.

From that point of view, I don't see a reason in rewriting the class
based generic-views as there is already Jacobian's take on it.

Russell Keith-Magee

unread,
May 11, 2010, 7:43:04 PM5/11/10
to django-d...@googlegroups.com
On Wed, May 12, 2010 at 1:35 AM, Jari Pennanen <jari.p...@gmail.com> wrote:
>
> On 11 touko, 03:37, Russell Keith-Magee <russ...@keith-magee.com>
> wrote:
>> show us the code!.
>>
>> [1] http://github.com/jacobian/django/tree/class-based-generic-views/django/views/generic2
>
> Yes, well. I have been in slight assumption that the above code is the
> one that will be merged. Though if it needs to be improved, I think
> Jacobian could *list the problems in his implementation* so others can
> try to improve on them, as he probably knows that code best.
>
> From that point of view, I don't see a reason in rewriting the class
> based generic-views as there is already Jacobian's take on it.

If you look at Jacob's code, you'll discover that Jacob's
implementation isn't complete. The edit views are still just stubs.
I've also seen comments about consistency between Jacob's
implementation and the class-based syndication views that are in
trunk.

That means there is still work to do, and someone needs to do it. If
you're going to volunteer to do the work, I don't think Jacob would
complain about getting assistance.

Yours,
Russ Magee %-)

Ben Firshman

unread,
May 12, 2010, 4:16:55 PM5/12/10
to django-d...@googlegroups.com

On 11 May 2010, at 01:37, Russell Keith-Magee wrote:
>
>
> Are class-based views planned for 1.3? Well, we haven't done any
> formal planning for 1.3 yet, but I'm going to guess that the 1.3 high
> priority feature list will essentially be "the features that got
> dropped from 1.2", so in all likelihood, yes. However, that doesn't
> mean that they will definitely be in 1.3 - someone still needs to do
> the implementation. If you really want class based generic views, be
> like Ben and make it happen -- show us the code!.

Oooh, class-based views.

This is something I've been thinking about a lot, and I'll probably dive into it at the Djangocon.eu sprints. Feel free to make a start Jari. ;)

Ben

fitzgen

unread,
May 12, 2010, 8:14:35 PM5/12/10
to Django developers, John Huddleston
I have been using class views at work that are based off of Jacob's
base GenericView class since last summer.

http://github.com/fitzgen/class_views/blob/master/views.py

Things that people haven't really mentioned, but need addressing, that
we had to find solutions for:

* How to do redirects in class based views? See lines 71-86 and 166.

* How to decorate the __call__ method without doing a pointless
override of __call__ that just calls super so that you have something
to @decorate on top of. Check out the meta class on line 175. This
allows you to specify 'decorators = [login_required,
permission_required("polls.can_vote")]' on your subclass. I showed
this to Jacob at DjangoSki, and he seemed positive.

* How to decorate methods, when the decorator expects the first
argument to be request, and not self. See line 8. Ideally though,
Django's decorators would handle this, rather than forcing the use of
decorate_method_with on to the end users.

* How to deal with state and self. I have written an instantiator that
wraps the view class and instantiates a new instance of the class for
every request so that everything is thread safe. This works, but
agian, it would be nice if Django checked to see if the callable being
linked to a url route is a class, in which case it would handle the
instantiation of a new instance for every request. See line 188.

Excited to get this stuff in to 1.3!

_Nick_

David Larlet

unread,
May 13, 2010, 6:00:14 AM5/13/10
to django-d...@googlegroups.com

Le 12 mai 2010 à 22:16, Ben Firshman a écrit :

>
> On 11 May 2010, at 01:37, Russell Keith-Magee wrote:
>>
>>
>> Are class-based views planned for 1.3? Well, we haven't done any
>> formal planning for 1.3 yet, but I'm going to guess that the 1.3 high
>> priority feature list will essentially be "the features that got
>> dropped from 1.2", so in all likelihood, yes. However, that doesn't
>> mean that they will definitely be in 1.3 - someone still needs to do
>> the implementation. If you really want class based generic views, be
>> like Ben and make it happen -- show us the code!.
>
> Oooh, class-based views.
>
> This is something I've been thinking about a lot, and I'll probably dive into it at the Djangocon.eu sprints. Feel free to make a start Jari. ;)

I'd love to sprint on this at EDC too.

Regards,
David

Jari Pennanen

unread,
May 13, 2010, 6:53:28 AM5/13/10
to Django developers
On 13 touko, 03:14, fitzgen <fitz...@gmail.com> wrote:
> * How to deal with state and self. I have written an instantiator that
> wraps the view class and instantiates a new instance of the class for

What about class method "instantiator"? It does have one extra nicety,
it does not need to be imported as one imports the view classes
already.

Then one could do: ``url(r'^path/$', ObjectView.instantiator(),
name="object_view")``

Thats mostly just syntactical sugar though, if it were class method I
would name it as create() or something...

But that is such a small detail at the moment it probably does not
matter.

Luke Plant

unread,
May 13, 2010, 7:08:26 AM5/13/10
to django-d...@googlegroups.com
On Thursday 13 May 2010 01:14:35 fitzgen wrote:

> * How to decorate the __call__ method without doing a pointless
> override of __call__ that just calls super so that you have
> something to @decorate on top of. Check out the meta class on line
> 175. This allows you to specify 'decorators = [login_required,
> permission_required("polls.can_vote")]' on your subclass. I showed
> this to Jacob at DjangoSki, and he seemed positive.

I personally don't like metaclasses if we can find another way. Here
are some alternatives which use Plain Old Python:

1) from Python 2.6 we could use class decorators, and we could use the
'old style' MyClass = some_class_decorator(MyClass) until we move to
Python 2.6.

2)
class Foo(View):
__call__ = some_decorator(View.__call__)


3) Add the decorators when you call 'instantiator' (which, by the way,
I would rather call 'make_view' or something more specific). You
would then have, *in views.py*:

3a) my_view = some_decorator(make_view(MyViewClass))

or possibly (though I don't think this adds much):

3b) my_view = make_view(MyViewClass,
decorators=[some_decorator])

This has some significant advantages:

- you don't need to worry about method decorators

- you can re-use MyViewClass with different decorators

- it protects us from changing the URLconf. The URLconf always
has a reference to the 'my_view' function, rather than
MyViewClass. Class-based views then remain an implementation
detail, just as they ought to be. It may well be that
a re-usable app provides some views and might switch
from class-based views to normal functions, and URLconfs
should be insulated from that change.

I don't like the idea of special-casing class based views anywhere,
whether to cope with state or anything else. I think a view should
still be 'a callable that takes a request and returns a response'. If
that means we have to add an extra line to create a view function from
a view class, so be it.

Given that it is going to be possible to use any/all of these whatever
Django provides, I think I'm quite strongly in favour of 3a), and
opposed to adding a metaclass which really doesn't add anything
significant. Metaclasses add complications for people attempting to
understand code, and should be used only when you really need them.

> * How to decorate methods, when the decorator expects the first
> argument to be request, and not self. See line 8. Ideally though,
> Django's decorators would handle this, rather than forcing the use
> of decorate_method_with on to the end users.

We already have 'django.utils.decorators.method_decorator' to cope
with this. All attempts to have decorators that automatically adapt
to functions/methods have failed. See my message here
http://groups.google.com/group/django-developers/msg/f36976f5cfbcbeb3
It has some attachments with test cases that show how our previous
attempt to do this didn't work in some situations.

One thing we could do to make it nicer for the end user is to create
our own 'method' versions of all supplied decorators i.e:

cache_page_m = method_decorator(cache_page)

for every decorator we provide, so that people don't need to do that
themselves.

However, this point may be moot given the discussion above.

Luke

--
"Mistakes: It could be that the purpose of your life is only to
serve as a warning to others." (despair.com)

Luke Plant || http://lukeplant.me.uk/

Nick Fitzgerald

unread,
May 13, 2010, 2:04:04 PM5/13/10
to django-d...@googlegroups.com
Luke,

Good points, especially about wrapping decorators *after* instantiation to avoid the whole nasty self issue.

While I personally don't mind meta classes at all, I understand why some people do.

I think you are probably on the right track here.

_Nick_

Reinout van Rees

unread,
May 14, 2010, 10:12:07 AM5/14/10
to django-d...@googlegroups.com
On 05/12/2010 10:16 PM, Ben Firshman wrote:
>
> This is something I've been thinking about a lot, and I'll probably dive into it at the Djangocon.eu sprints.

I'll be there at the djangocon.eu sprints, but I can't find extra
information about that. Are there actions I need to handle beforehand?

I'm used to Plone sprints and there's usually some "make sure you have
svn access to x and y" stuff best handled *before* the sprint, that's
why I'm asking :-)


Reinout

--
Reinout van Rees - rei...@vanrees.org - http://reinout.vanrees.org
Programmer at http://www.nelen-schuurmans.nl
"Military engineers build missiles. Civil engineers build targets"

Jeremy Dunck

unread,
May 14, 2010, 10:27:00 AM5/14/10
to django-d...@googlegroups.com
On Fri, May 14, 2010 at 9:12 AM, Reinout van Rees <rei...@vanrees.org> wrote:
...
> I'm used to Plone sprints and there's usually some "make sure you have svn
> access to x and y" stuff best handled *before* the sprint, that's why I'm
> asking :-)

This might help:
http://code.djangoproject.com/wiki/Sprints

If you have questions after that, let me know -- I'd be happy to
improve that page.

Harro

unread,
May 14, 2010, 12:28:59 PM5/14/10
to Django developers
Ah crap.. now you've done it.. now I want to be at the djangocon.eu
sprints too..
Why do all the fun things always happen at the same time..
I guess I could stay the thursday. and then go home on friday.

Ah well.. I'll have till monday to think about it.

On May 14, 4:27 pm, Jeremy Dunck <jdu...@gmail.com> wrote:

Reinout van Rees

unread,
May 14, 2010, 5:02:05 PM5/14/10
to django-d...@googlegroups.com
On 05/14/2010 04:27 PM, Jeremy Dunck wrote:
> On Fri, May 14, 2010 at 9:12 AM, Reinout van Rees<rei...@vanrees.org> wrote:
> ...
>> I'm used to Plone sprints and there's usually some "make sure you have svn
>> access to x and y" stuff best handled *before* the sprint, that's why I'm
>> asking :-)
>
> This might help:
> http://code.djangoproject.com/wiki/Sprints

Yes, it does help :-) I've added a link to that page on the djangocon.eu
wiki sprint page.

> If you have questions after that, let me know -- I'd be happy to
> improve that page.

That page is fine. The page linked from there that tells you how to set
up an svn trunk django got me frowning a bit: "symlink django trunk into
your system python". Ehm, I'd rather isolate it with virtualenv or
buildout to keep trunk's stuff out of the rest of my django projects.

So: is that just a missing piece of documentation? Or is the virtualenv
kind of isolation rarely done when developing on trunk?


Reinout

Jeremy Dunck

unread,
May 14, 2010, 5:06:37 PM5/14/10
to django-d...@googlegroups.com

On May 14, 2010, at 4:02 PM, Reinout van Rees <rei...@vanrees.org>
wrote:
> That page is fine. The page linked from there that tells you how to
> set up an svn trunk django got me frowning a bit: "symlink django
> trunk into your system python". Ehm, I'd rather isolate it with
> virtualenv or buildout to keep trunk's stuff out of the rest of my
> django projects.
>
> So: is that just a missing piece of documentation? Or is the
> virtualenv kind of isolation rarely done when developing on trunk?

I'm pretty sure it's just that it was written before virtualenv was
made. I should be updated. I use ve on dj dev often.

Luke Plant

unread,
May 27, 2010, 12:07:13 PM5/27/10
to django-d...@googlegroups.com
On Thursday 13 May 2010 12:08:26 Luke Plant wrote:

> 3) Add the decorators when you call 'instantiator' (which, by the
> way, I would rather call 'make_view' or something more specific).
> You would then have, *in views.py*:
>
> 3a) my_view = some_decorator(make_view(MyViewClass))
>
> or possibly (though I don't think this adds much):
>
> 3b) my_view = make_view(MyViewClass,
> decorators=[some_decorator])
>

I had some more thoughts about this. One problem with applying the
decorators after is if someone is re-using the class (e.g.
subclassing), but forgets to apply some *necessary* decorators when
creating the view from it. One work-around is that 'make_view' checks
the class itself for a 'decorators' attribute, and applies them:

def make_view(viewclass):
def view(request, *args, **kwargs):
obj = viewclass()
return obj(request, *args, **kwargs)

for f in getattr(viewclass, 'decorators', []):
view = f(view)

return view

This would make it harder to forget, but would still allow subclasses
to adjust the decorators that are used by default. It won't help in
the case where people use the class directly in the URLconf, but I
don't think that should be encouraged anyway.

Luke

--
"Oh, look. I appear to be lying at the bottom of a very deep, dark
hole. That seems a familiar concept. What does it remind me of? Ah,
I remember. Life." (Marvin the paranoid android)

Luke Plant || http://lukeplant.me.uk/

David Larlet

unread,
May 27, 2010, 12:29:28 PM5/27/10
to django-d...@googlegroups.com
Hello,

We're working on this with Ben during djangocon.eu sprint [1]. Any comment appreciated, still a work in progress though.

Regards,
David

[1] http://github.com/bfirsh/django-class-based-views


Luke Plant

unread,
May 27, 2010, 6:01:51 PM5/27/10
to django-d...@googlegroups.com
On Thursday 27 May 2010 17:29:28 David Larlet wrote:
> Hello,
>
> We're working on this with Ben during djangocon.eu sprint [1]. Any
> comment appreciated, still a work in progress though.

Looks cool. I think Jari's idea of a class method to instantiate the
classes would be a great pattern to establish - something like an
'as_view' classmethod on the base class which returns a view function
that uses the class:

@classmethod
def as_view(cls, *initargs, **initkwargs):
def view(*args, **kwargs):
obj = cls(*initargs, **initkwargs)
return obj(*args, **kwargs)
return view

The developer can choose whether to write 'MyClassView.as_view()'
directly into the URLconf, or put a line into views.py like 'my_view =
MyClassView.as_view()'

This will solve the thread safety issue, and doesn't require another
import for a decorator, as Jari pointed out.

We could decide whether to apply decorators inside as_view() or
__call__(). The argument for putting it in 'as_view' is that __call__
does some processing that you might want to skip entirely (e.g. the
get_object() call - if we applied a 'cache_page' decorator, we
wouldn't want the get_object() call to be made at all if there was a
cache hit).

On that point, I think 'GenericView' should be split into 'ClassView'
and 'GenericView'. The get_object() call is probably not a good thing
to have on a base class.

Regards,

David Larlet

unread,
May 28, 2010, 4:03:02 AM5/28/10
to django-d...@googlegroups.com

We discussed that point with Jacob and it looks like it's easier to modify urlresolvers to create a new instance of the class when we detect it's a class, this should solve the thread safety issue. Do you see any drawback to this approach?
That way we can declare decorators via a decorators' list [1] or directly in the class [2]. I'm not fond of the second way, decorating a decorator, but we can create decorators dedicated to class based views easily that way.


>
> On that point, I think 'GenericView' should be split into 'ClassView'
> and 'GenericView'. The get_object() call is probably not a good thing
> to have on a base class.

Agreed, I'll make that change.

Thanks,
David

[1] http://github.com/bfirsh/django-class-based-views/blob/master/class_based_views/tests/views.py#L24
[2] http://github.com/bfirsh/django-class-based-views/blob/master/class_based_views/tests/views.py#L43

Luke Plant

unread,
May 28, 2010, 9:41:36 AM5/28/10
to django-d...@googlegroups.com
On Friday 28 May 2010 09:03:02 David Larlet wrote:

> > This will solve the thread safety issue, and doesn't require
> > another import for a decorator, as Jari pointed out.
> >
> > We could decide whether to apply decorators inside as_view() or
> > __call__(). The argument for putting it in 'as_view' is that
> > __call__ does some processing that you might want to skip
> > entirely (e.g. the get_object() call - if we applied a
> > 'cache_page' decorator, we wouldn't want the get_object() call
> > to be made at all if there was a cache hit).
>
> We discussed that point with Jacob and it looks like it's easier to
> modify urlresolvers to create a new instance of the class when we
> detect it's a class, this should solve the thread safety issue. Do
> you see any drawback to this approach?

I'm sure that will work. My main reluctance is using isinstance()
when it isn't necessary, and having to change the definition of what a
'view' is when it isn't strictly necessary. (A view is no longer
simply "a callable that takes a request and returns a response"). I
guess this is partly about aesthetics, and I know practicality beats
purity, but:

There might also be the following practical disadvantages when it
comes to the API we encourage.

If the recommended usage is to do:
urlpatterns = ...
(r'something/', MyClassView)
...

then it would be easy to accidentally do `MyClassView()`, and it would
appear to work fine, until you later get thread safety issues. Also,
if you want to pass arguments to the constructor, you would most
naturally do `MyClassView(somearg=something)`, and again it would
appear to work.

If, however, we encouraged `MyClassView.as_view()` from the start, we
can cope with constructor arguments more easily - it changes to
`MyClassView.as_view(somearg=something)`.

(Either way, it would still be possible to pass in MyClassView() and
get thread safety problems, but it's about making mistakes less
natural).

Of course, if we want to use dotted path syntax in URLconfs -
"path.to.MyClassView" - rather than imports, then we would *need* to
have the isinstance() check to be able to cope with it at all. My
response to that is: my preference would be that the use of class
based views should remain an implementation detail, and as far as the
URLconf is concerned, views.py should be exporting a ready-to-use
callable not the class. (The class is exported for the purpose of
other people subclassing, or passing their own constructor arguments,
not for direct use in the URLconf).

There is also the issue of what to do when you need to add a decorator
to someone else's view function. As a developer, I shouldn't have to
know that class based views even *exist*, let alone how to use them,
if I'm just a client - I should *always* be able to say:

from someapp.views import some_view_function
my_view_function = login_required(some_view_function)

But if someapp.views has only exported SomeClassView and not
some_view_function, I now have to do something different.

Given that, for many Django apps, the view functions are part of the
public API that needs to be exported (i.e. hooked into people's
URLconfs or wrapped for re-use), I think it would be good to encourage
practices which will lead to stable and consistent APIs, and so *not*
allow or encourage classes to be used directly in the URLconf.

Jacob Kaplan-Moss

unread,
May 28, 2010, 10:51:32 AM5/28/10
to django-d...@googlegroups.com
This is a bit of a tricky thing to discuss since we've been talking
about this IRL at the sprints, and also on the list. I'll try to sum
up where we are now, but if anything isn't clear, ask.

We're currently working towards URLpatterns of the form::

('...', SomeView)

i.e. passing a class directly, which would be instantiated implicitly
then called.

The reason we're trying it this way is thread safety: if a view is a
class, then people *will* store state on self. So if we have single
instances in views like we do now, then we're giving folks enough rope
to hang themselves. By having each request get a fresh instance we
avoid that problem.

The other alternative we discussed was having the base view class do
something with threadlocals to make sure state saved on self is
threadsafe. I vetoed that because I hate threadlocals :)

On Fri, May 28, 2010 at 3:41 PM, Luke Plant <L.Pla...@cantab.net> wrote:
> I'm sure that will work.  My main reluctance is using isinstance()
> when it isn't necessary, and having to change the definition of what a
> 'view' is when it isn't strictly necessary. (A view is no longer
> simply "a callable that takes a request and returns a response").

I *am* a bit worried by this -- I'm not sure redefining the definition
of "view" is such a good idea. "A view is a callable or a class with
callable instances" isn't nearly as simple and nice a recommendation.

> If, however, we encouraged `MyClassView.as_view()` from the start, we
> can cope with constructor arguments more easily - it changes to
> `MyClassView.as_view(somearg=something)`.

My only real objection here is that `as_view` is just a bunch of boilerplate::

urlpatterns = patterns('',
('one/', SomeView.as_view()),
('two/', SomeOtherView.as_view()),
('three', YourView.as_view())
)

I just really don't like the way that looks.

As for accepting extra __init__ arguments: I specifically *don't* want
to allow this (at least easily) because I want to encourage
subclassing as the "correct" way of extending views. Yes, this means a
slight loss of flexibility, but it also means that we're forcing
people into a more extensible and fuure-proof way of coding, and
that's a good thing.

> (Either way, it would still be possible to pass in MyClassView() and
> get thread safety problems, but it's about making mistakes less
> natural).

... and either way it's pretty easy to issue a warning if you've
subclassed ``django.views.View`` (my proposed name for the view base
class) and re-used it for multiple requests.

> There is also the issue of what to do when you need to add a decorator
> to someone else's view function.

Again, I want to encourge "subclass it" as the correct answer here.

> Given that, for many Django apps, the view functions are part of the
> public API that needs to be exported (i.e. hooked into people's
> URLconfs or wrapped for re-use), I think it would be good to encourage
> practices which will lead to stable and consistent APIs, and so *not*
> allow or encourage classes to be used directly in the URLconf.

I think we're in agreement here -- we're both trying to avoid view-ish
stuff in the URLconfs (a la the old way we used to do generic views
with dicts in urls.py).

Having played with it for a few years now, though, I'm finding
subclassing is really the best way to make this happen.

So reusable apps instead of exporting functional views export
class-based ones; users who want to re-use them import, subclass, and
extend.

Jacob

Ben Firshman

unread,
May 28, 2010, 11:14:12 AM5/28/10
to django-d...@googlegroups.com
If a class-based view by definition is instantiated on each request, we get a couple of neat things. For example, storing state on self.

Storing state on self makes things a heck of a lot easier. We are going to create a "View" and a "ResourceView". A View just renders a template, but a ResourceView has some kind of resource attached to it (model instance, QuerySet, whatever). On View, this would be the get_context() signature (where args and kwargs are from the URL):

def get_context(self, request, *args, **kwargs):
....

When we create ResourceView, we need to pass the resource in here somehow, interfering with args and kwargs:

def get_context(self, request, resource, *args, **kwargs):
....

We would have to redefine all the methods which require the resource. It seems neater to store it on self.

We have solved accidentally instantiating the view by raising an exception if a View instance is called twice. Of course, people who understand the threading issues are free to create their own class-based views.

I like this method because of its transparency. I fear having to explain as_view() in the documentation. Thread problems are hard to understand.

Ben

Luke Plant

unread,
May 28, 2010, 7:07:39 PM5/28/10
to django-d...@googlegroups.com
On Friday 28 May 2010 15:51:32 Jacob Kaplan-Moss wrote:

> My only real objection here is that `as_view` is just a bunch of
> boilerplate::
>
> urlpatterns = patterns('',
> ('one/', SomeView.as_view()),
> ('two/', SomeOtherView.as_view()),
> ('three', YourView.as_view())
> )
>
> I just really don't like the way that looks.

Agreed. I also think that if you have a mixture of normal views and
class based view, this is ugly:

urlpatterns = patterns('app.views',
('one/', 'some_view_function',
('two/', SomeOtherView),
('three/', YourView)
)

and it would be nicer to spell it:

urlpatterns = patterns('app.views',
('one/', 'some_view_function'),
('two/', 'some_other_view'),
('three/', 'your_view')
)

and have these additional lines in 'app.views':

some_other_view = SomeOtherView.as_view()
your_view = YourView.as_view()

I know that is just moving the boilerplate around, but it is giving a
consistent interface. If some code in a re-usable app moves from
normal views to class based views, they will have to do something like
this *anyway* for backwards compatibility.

But I can see that if subclassing is the default way of re-using, then
exporting these functions gives multiple options about how they should
be re-used, which you are wanting to avoid.

> > There is also the issue of what to do when you need to add a
> > decorator to someone else's view function.
>
> Again, I want to encourge "subclass it" as the correct answer here.

In that case, I guess it would be good to make this hard to do wrong,
by providing helpers that add the decorator to the right end of the
list of decorators.

Ben Firshman

unread,
May 29, 2010, 5:06:37 PM5/29/10
to django-d...@googlegroups.com
Luke, you're absolutely right that changing the definition of a view is a bad idea, it just seemed the best solution then.

But don't worry, we've changed our minds again! If __call__() creates a copy of self and calls methods on the copy, as far as I can see it solves all our problems. No boilerplate, and it's really hard to make it unsafe thread-wise.

An example of how it could work:

http://github.com/bfirsh/django-class-based-views/blob/master/class_based_views/base.py

Thanks

Ben

Waldemar Kornewald

unread,
May 30, 2010, 3:24:08 AM5/30/10
to Django developers
Maybe I missed something, but why don't you use __new__ instead of
copying the instance?

Bye,
Waldemar

On May 29, 11:06 pm, Ben Firshman <b...@firshman.co.uk> wrote:
> Luke, you're absolutely right that changing the definition of a view is a bad idea, it just seemed the best solution then.
>
> But don't worry, we've changed our minds again! If __call__() creates a copy of self and calls methods on the copy, as far as I can see it solves all our problems. No boilerplate, and it's really hard to make it unsafe thread-wise.
>
> An example of how it could work:
>
> http://github.com/bfirsh/django-class-based-views/blob/master/class_b...

henning....@gmail.com

unread,
Jun 1, 2010, 6:43:30 AM6/1/10
to Django developers
On May 30, 7:24 am, Waldemar Kornewald <wkornew...@gmail.com> wrote:
> Maybe I missed something, but why don't you use __new__ instead of
> copying the instance?
Here is an example where I used __new__ for class based views in my
project:
http://djangosnippets.org/snippets/2046/
No __call__ or as_view is needed with this approach.
I can easily replace a function with a class without changing the url
configuration.

Regards,
Henning

Roald

unread,
Jun 2, 2010, 11:08:24 AM6/2/10
to Django developers
Maybe I've missed the reason, or it's just too late to change, but why
not using a class itself (so basically its __init__ method) as a view.
I'm using something like this in my projects (as a base class):

class View(HttpRequest):
def __init__(self, request, *args, **kwargs):
...
super(View, self).__init__(self.content())
...

You can find it (the commit at time of writing) on
http://github.com/roalddevries/class_based_views/blob/10b5e4016c755164c20126f14870c41dc88b9c03/views.py.

An advantage of this is that url patterns of the form ('...', my_view)
can be user, where my_view is just a class derived from View. I also
think that the solution to redirection (lines 32-39) is pretty
elegant.

I'm looking forward to your comments.

Cheers, Roald

Luke Plant

unread,
Jun 2, 2010, 5:22:19 PM6/2/10
to django-d...@googlegroups.com
On Wednesday 02 June 2010 16:08:24 Roald wrote:
> Maybe I've missed the reason, or it's just too late to change, but
> why not using a class itself (so basically its __init__ method) as
> a view. I'm using something like this in my projects (as a base
> class):
>
> class View(HttpRequest):
> def __init__(self, request, *args, **kwargs):
> ...
> super(View, self).__init__(self.content())
> ...
>

You mean:

class View(HttpResponse):
...

One reason against this is it makes it harder to re-use other views
from within the View. You are forced to mutate the 'self' instance of
HttpResponse (or else use some nasty hack), rather than being able to
simply return the HttpResponse that might be returned from a utility
function or a sub-view.

Luke Plant

unread,
Jun 2, 2010, 5:31:41 PM6/2/10
to django-d...@googlegroups.com

This is an interesting approach. The only downside I can think of at
the moment is that implementing __new__() like that really violates
expectations - Python programmers have a fairly strong expectation
that if you do 'x = SomeClass()', where SomeClass is defined as a
class, then x will be an instance of SomeClass.

Ben Firshman

unread,
Jun 2, 2010, 6:20:52 PM6/2/10
to django-d...@googlegroups.com

On 2 Jun 2010, at 22:31, Luke Plant wrote:

> On Tuesday 01 June 2010 11:43:30 henning....@gmail.com wrote:
>> On May 30, 7:24 am, Waldemar Kornewald <wkornew...@gmail.com> wrote:
>>> Maybe I missed something, but why don't you use __new__ instead
>>> of copying the instance?
>>
>> Here is an example where I used __new__ for class based views in my
>> project:
>> http://djangosnippets.org/snippets/2046/
>> No __call__ or as_view is needed with this approach.
>> I can easily replace a function with a class without changing the
>> url configuration.
>
> This is an interesting approach. The only downside I can think of at
> the moment is that implementing __new__() like that really violates
> expectations - Python programmers have a fairly strong expectation
> that if you do 'x = SomeClass()', where SomeClass is defined as a
> class, then x will be an instance of SomeClass.

Yeah, this idea came up at the sprints, but it's a little too magic for my tastes.

Ben

Horst Gutmann

unread,
Jun 2, 2010, 7:03:13 PM6/2/10
to django-d...@googlegroups.com
On Sat, May 29, 2010 at 11:06 PM, Ben Firshman <b...@firshman.co.uk> wrote:
> Luke, you're absolutely right that changing the definition of a view is a bad idea, it just seemed the best solution then.
>
> But don't worry, we've changed our minds again! If __call__() creates a copy of self and calls methods on the copy, as far as I can see it solves all our problems. No boilerplate, and it's really hard to make it unsafe thread-wise.
>
> An example of how it could work:
>
> http://github.com/bfirsh/django-class-based-views/blob/master/class_based_views/base.py
>
> Thanks
>
> Ben

Hi :-)

I'm not really sure about that approach. As with __new__, __call__
comes (at least for me) with a bunch of expectations. For me it
executes and operates on one single instance of an object. Sure, this
could be interpreted as using the instance as a factory for usually
you'd use class methods for something like that, but still.

On the other hand I can definitely see the merit in it since you could
then easily programmatically modify the "view" factory by just
modifying "yet another object".

-- Horst

Waldemar Kornewald

unread,
Jun 3, 2010, 2:59:11 AM6/3/10
to Django developers
On Jun 2, 11:31 pm, Luke Plant <L.Plant...@cantab.net> wrote:
> On Tuesday 01 June 2010 11:43:30 henning.schroe...@gmail.com wrote:
>
> > On May 30, 7:24 am, Waldemar Kornewald <wkornew...@gmail.com> wrote:
> > > Maybe I missed something, but why don't you use __new__ instead
> > > of copying the instance?
>
> > Here is an example where I used __new__ for class based views in my
> > project:
> >http://djangosnippets.org/snippets/2046/
> > No __call__ or as_view is needed with this approach.
> > I can easily replace a function with a class without changing the
> > url configuration.
>
> This is an interesting approach.  The only downside I can think of at
> the moment is that implementing __new__() like that really violates
> expectations - Python programmers have a fairly strong expectation
> that if you do 'x = SomeClass()', where SomeClass is defined as a
> class, then x will be an instance of SomeClass.

Yes, that's indeed not perfect. However, the instance-based approach
is not thread-safe, so we'll have to go with a class-based approach.
The only alternative, then, is to extend Django's URL handling code to
automatically instantiate classes, but then calling a class-based view
would require manually instantiating the class. Yes, __new__ does some
magic, but it at least solves all other problems. Kind of reminds me
of the CAP theorem: no magic, easily callable, thread safe. Pick
two. :)

Bye,
Waldemar Kornewald

Roald

unread,
Jun 3, 2010, 3:59:31 AM6/3/10
to Django developers
On 2 jun, 23:22, Luke Plant <L.Plant...@cantab.net> wrote:
> On Wednesday 02 June 2010 16:08:24 Roald wrote:
> >     class View(HttpRequest):
> >         def __init__(self, request, *args, **kwargs):
> >             ...
> >             super(View, self).__init__(self.content())
> >         ...
>
> You mean:
>
>      class View(HttpResponse):
>          ...

That's what I meant, yes.

> One reason against this is it makes it harder to re-use other views
> from within the View.

I don't really understand what you mean. Do you mean re-using 'good'
old function-views?

> You are forced to mutate the 'self' instance of
> HttpResponse (or else use some nasty hack),

No nasty hacks, just mutate 'self' from inside its class instead of
from outside.

> rather than being able to
> simply return the HttpResponse that might be returned from a utility
> function or a sub-view.

The other options presented in this topic (using __call__, __new__ or
View.as_view) all have their drawbacks, and personally I think I like
__init__ best:
- the __call__-option requires a different interpretation of url
patterns
- the __new__-option is actually a hack, does unexpected things and
thus is less readable, and is I think more complex that the __init__-
option
- the static/class method option is not really an improvement over
global functions, and leads to url patterns with more 'boiler plate
code'
- the __init__-option is only as complex as any Django programmer
should understand.

But even if you think that using __init__ is more complex than writing
a utility function: no worries. Normally you will use it something
like this:

class myview(View):
template_file = 'myapp/template.html'

@property
def context_dict(self):
return {'authenticated':
self.request.user.is_authenticated()}

... which you can hardly call complicated.

Carl Meyer

unread,
Jun 3, 2010, 12:45:38 PM6/3/10
to Django developers
On Jun 2, 6:20 pm, Ben Firshman <b...@firshman.co.uk> wrote:
> Yeah, this idea came up at the sprints, but it's a little too magic for my tastes.

I dunno... is __new__ really more magic than having a __call__ method
that magically copies the instance you call it on? That certainly
breaks my expectations.

Django doesn't shy away from "magic" in other areas where it makes for
a usable API. The things that happen to model and form fields
certainly violate the initial expectations of a Python programmer; but
it turns out that most people are happy to write readable models and
don't care what's happening under the hood, and those who do care can
learn a little something about metaclasses. Seems to me that __new__
is a relatively beautiful solution to a thorny problem: it lets people
use class views in all the same ways they use function views while
maintaining thread-safety, it maintains the "callable that returns
HttpResponse" contract, and most people won't ever see or care about
the "magic" that makes it work.

+1 for __new__.

Carl

Ben Firshman

unread,
Jun 3, 2010, 1:10:32 PM6/3/10
to django-d...@googlegroups.com

One advantage of using __call__ over __new__ is passing arguments to __init__. That's handy for lazily configuring views:

(r'', DetailView(queryset=Thing.objects.all())

Ben

Alex Gaynor

unread,
Jun 3, 2010, 1:13:37 PM6/3/10
to django-d...@googlegroups.com
> --
> You received this message because you are subscribed to the Google Groups "Django developers" group.
> To post to this group, send email to django-d...@googlegroups.com.
> To unsubscribe from this group, send email to django-develop...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
>
>

I thought we said we really wanted to encourage using subclassing to
solve these problems (providing many types of args in urls.py can
cause problems).

Alex

--
"I disapprove of what you say, but I will defend to the death your
right to say it." -- Voltaire
"The people's good is the highest law." -- Cicero
"Code can always be simpler than you think, but never as simple as you
want" -- Me

Waldemar Kornewald

unread,
Jun 3, 2010, 1:18:38 PM6/3/10