On Thu, Jun 17, 2010 at 6:49 PM, Waldemar Kornewald <wkornew...@gmail.com> wrote: > The one-instance approach is no more thread-safe than having a global > variable. In your example nothing bad will happen, but once we get to > some real-world reusable views you'll quickly see a need for saving > thread-local state somewhere. We had that problem with Django's Feed > class, for example, where we needed access to the request in one of > the methods and the only workaround was to instantiate a new Feed for > every request and manually inject a _request attribute. The point is > that in a class-based view you normally have lots of methods for > customizing the view's behavior, so either you pass the whole > thread-local state as arguments to every single method (which is > *very* ugly and tedious) or you save that state in self. Also, the > problem with passing lots of arguments around is that it can make > adding more variables to the current state and thus customizability > difficult. There's no way around allowing thread-local state and the > one instance per request approach solves this elegantly.
So the only limitation is that you don't want to pass parameters to methods? <sarcasm>Good thing self is passed implicitly or classes would be totally useless!</sarcasm> ;) More seriously: Explicit is better than implicit. Simple is better than complex. [...] If the implementation is hard to explain, it's a bad idea. -- Patryk Zawadzki -- 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.
