On Thu, Jun 17, 2010 at 6:57 PM, Patryk Zawadzki <pat...@pld-linux.org> wrote: > 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?
Imagine what the code would look like with parameter passing: class View(object): def __call__(self, request, **kwargs): qs = self.get_queryset(request, **kwargs) ..... def get_queryset(self, request, **kwargs): ... Now someone writes a reusable view for S3 file management which only has one parameter (bucket_name) and publishes the code as an open-source project: class S3View(View): def get_queryset(request, bucket_name, **kwargs): self.get_bucket(bucket_name) ... ... Then you want to use his code in your project: class MyS3View(S3View): def get_bucket(self, bucket_name): # oh no! I need the request and the other configuration paramters here! :( Now you have a problem because the other developer was too lazy to pass request and **kwargs to that little "unimportant" get_bucket method. This happens in practice and our job is to come up with a design that makes this impossible or very unlikely. If the one-instance-per-request solution solves this and saves you from typing **kwargs all over the place then it absolutely is better, hands down. Bye, Waldemar Kornewald -- 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.