On Sun, Oct 3, 2010 at 8:02 PM, Russell Keith-Magee <russ...@keith-magee.com> wrote: >> Other frameworks seem have View/Handler instances per request, such as >> appengine's webapp so there is some precedent for creating an instance >> per request. >> >> http://code.google.com/appengine/docs/python/gettingstarted/handlingforms.html > > I don't think you'll find any argument that having an instance per > request would solve all the problems that this thread has described. > The issue is how to declare a view that is able to be instantiated on > a instance-per-request basis while simultaneously allowing decorators > to be easily wrapped around that view.
I was sort of referring to the __new__() method you are describing to allow state to be stored on self. A class instance that can be wrapped by a decorator to me is simply a callable instance and people are just going to have to get used to the idea that self can't be modified safely. Anything else is a bad hack that will likely cause even more headaches down the road. That said, even Django itself has code that falls victim to storing state on self in a callable class based view (See: django.contrib.formtools.preview.FormPreview). So I can imagine many people will be confused, but it is what it is. -- Ian http://www.ianlewis.org/ -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@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.
