Functional Functions and the Python Singleton Unpattern

[glyf]

Have you ever written a module that looked like this?
subscribers = []

def addSubscriber(subscriber):
    subscribers.append(subscriber)

def publish(message):
    for subscriber in subscribers:
        subscriber.notify(message)

And then used it like this?
from publisher import publish

class worker:
    def work(self):
        publish(self)

I've

Comments

[glyf]

I'm curious, how did you test the Singleton classes before using this pattern? At work we actually ask people during interviews to describe their experiences with singletons, and people have consistently reported that testing is highly problematic, and control of scope even more so.
It's Python. Some things are horrible, but everything is testable. For example, consider this little gem:
class Thing

[glyf]

Oh, sure, it's tedious and unpleasant in Java, but hey - you are using Java, clearly you like tedious and unpleasant things :). But it's often possible even without bytecode hacking.

For example, libraries like JMock achieve similar, if not identical, results by using java.lang.reflect.Proxy and friends.

(And who says bytecode manipulation has to be hard.)

[glyf]

I use Spring (an IoC container on the Java side) for much of the configuration I use, since it encapsulates the scope (instance per VM/session/etc) and insertion into the appropriate objects. What do you do with the apps you build in python?
I have to confess I don't really understand this question. I have heard it before, and I keep my ear to the ground in the Java-verse, so I hear periodic murmurs about something or other totally revolutionizing Java programming by providing an even newer, even improveder way to initialize configuration and state and manage the lightweight dependency injection of control configuration inversion rama rama ding dong.

I would say "I don't think it's that big of a problem" if I even understood what the problem was that these massive configuration and initialization "container" frameworks were trying to solve. I assume it's not that big of a problem because I seem to be able to solve something similar by spending 30 seconds every six months writing a tac file, or these days maybe a whole ten minutes

[glyf]

I'll assume you know what IoC is and skip to the "Why I use it" part. Maybe these aren't issues in Python/Twisted (...)
I understand what the design pattern is, I've read fowler's paper, and it's a nice idea when it's appropriate, but it seems necessary so often in the Java universe that something appears distorted to me.
*Why* this situation occurs is probably more interesting than the solution
I believe that's the thing that I'm missing, so yes, I'm curious about it.
So, I can write a simpler class that just "magically" has a DB connection, rather than figuring out how to get the connection in the class itself (usually a bit of work in Java, and inflexibly changed).
Basically, I try to avoid this kind of magic. Pass parameters where you need 'em, when you are passing too many parameters at once, group them and turn them into objects. Nevow has a "magic" object, the "context", which you can get all kinds of juicy awfulness out of, but we are desperately trying to phase it out in favor of people just constructing objects that have all