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