> Ah.. the singleton... Java's answer to the fact that not everything is > an object. :-)
Ha ha, fair enough Russ :) And I don't dispute a certain java- oriented predisposition to the way i think about these problems. But let me bring a point in favor of the Singleton, and why I think it might actually remain relevant even in the world of python. [ First though, we're digressing a little off topic, so I wanted to thank Michael Elsdörfer for his point about a services directory. That's probably what I'll end up doing here once my services.py module grows too large. Cheers] Static methods are generally speaking not a good replacement for singletons, in as much as they force you to mix your configuration/ setup with your execution. There's no good way to pre-configure a static method (without resorting to globals), and then use that configured method later. As a case in point, I was recently reading James' very good article about using context processors (http://www.b- list.org/weblog/2006/jun/14/django-tips-template-context-processors/), where he suggests using RequestContext instead of Context to render your views. It's a very good idea, but it suffers from a DRY usability concern related to the pervasive use of the render_to_response() shortcut commonly employed by Django apps. Because render_to_response() is a static method, there's no good way to pre-configure it to use RequestContext instead of Context, which means that you must ensure that you must set context_instance in EVERY use of render_to_response in your view. eg. render_to_response(..., initial_context=RequestContext(request)). If you ever forget this one detail, you might end up with a funny looking page. If render_to_response() belonged to a singleton, though, then we could configure that singleton up front to use RequestContext as its context_instance, and none of our views would ever need to worry about that particular detail. You might imagine something like the following in django's core library: class RenderService: context_instance = Context() def render_to_response(*args, **kwargs): ... render_instance = RenderService() In my views.py I might want to use the default config and do something like the following: from django.shortcuts import render_instance def my_view(): return render_instance.render_to_response(...) But in my complicated_views.py, I might want to do something a little fancier using the RequestContext instead: from django.shorcuts import RenderService render_instance = RenderService(initial_context=RequestContext()) def my_complicated_view(): return render_instance.render_to_response(...) My views methods never need to know the details about which context is being used. They just set up their contexts and render their views as normal. (I do recognize that there are a couple of gaps in this example, in particular how to get the request object to the RequestContext, but please don't hold that against my defense of the poor concept of the Singleton. Hopefully the benefits of the singleton still come across.) Basically, using a Singleton[1] allows us to use the default instance supplied by the module for most cases, or instead use our own user- supplied instance if we desire specific configuration, all without requiring us to painstakingly modify every call to render_to_response() in all of our views. And it also protects us from one module making a global change to the render_to_response() configuration in a way that unexpectedly affects other modules.[2] So I think the Singleton is still relevant. Perhaps it doesn't have to be a class instance in python, perhaps there is a way to make a python module be the singleton instead. I suspect not since I don't se how you could avoid side-effects in that case, but I'm still new to the language. Cheers, Mike [1] One might claim that our Singleton in this example is really more of a pseudo-Singleton, since we allow the user to override the default instance with one of their own, should they so desire. [2] It appears that Random in python's core library does something like this, by using a "hidden" Random instance that you can override with your own instance if you need to. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~----------~----~----~----~------~----~------~--~---
