On Oct 2, 6:46 pm, Luke Plant <l.plant...@cantab.net> wrote: > On Sat, 2010-10-02 at 09:20 -0700, George Sakkis wrote: > > Having said that, I'm in favour of the first approach mentioned in the > > wiki (store state on request) and I'm surprised it doesn't seem to > > have any traction in this thread. The only argument against is "it's > > unusual to have a class where you can't store state on self" but even > > that can be overcome with an appropriate __setattr__/__getattr__ that > > access self.request.state under the hood. Unless someone tries > > self.__dict__[attr], it will look as if the state is stored on the > > view although it's actually stored in the request (or better > > request.state to avoid name clashes). Perhaps I am missing something > > but this seems to me foolproof and much cleaner than the alternatives. > > This breaks if you set any values in __init__ - since the request object > doesn't exist to store state on.
Ah, good point. In any case, the argument against is reduced to "It's unusual to have a class where you can't store state on self while in the __init__". The __call__ and copy proposal has this limitation too, while being more error prone and less efficient overall. George -- 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.
