Borg vs. Module

[tobiah]

I am making a web app, made up of many modules
that all need access to some important data, like
the current session data, cookies, navigation history,
post/get variables, etc.

I decided to go with the 'Borg' idea, by assigning the
__dict__ of an object to a class variable so that each
instantiation of the Borg() would share the same data.
That way I can either pass the Borg around, or just
Borg() it if I need it in some obscure place.

Then I read an argument that it usually makes more sense
to just have a module with the data and functions that
I need, which all the other modules can simply import.
Since I only need one instance, I could just stuff data
and call 'methods' on this module, probably without even
changing existing syntax.

Are there any arguments as to which method is better?

Thanks,

Toby

 

[Simon Hibbs]

For example, the Twisted framework uses this technique to allow global
access to the installed reactor via import syntax, which works well
within the framework. It did, however, throw me a bit when I first
encountered it, and drove me to pour over the source to find out what
was happening.

It sounds to me like this was a case of poor code commenting in Twisted
(Iv'e not looked at it myself). It seems to me this is a useful trick,
but like any unusual or clever bit of coding it's use should be
carefully commented to make sure it's clear to anyone coming across it.

Simon Hibbs

 

[Carl Banks]

I am making a web app, made up of many modules
that all need access to some important data, like
the current session data, cookies, navigation history,
post/get variables, etc.

I decided to go with the 'Borg' idea, by assigning the
__dict__ of an object to a class variable so that each
instantiation of the Borg() would share the same data.
That way I can either pass the Borg around, or just
Borg() it if I need it in some obscure place.

Then I read an argument that it usually makes more sense
to just have a module with the data and functions that
I need, which all the other modules can simply import.
Since I only need one instance, I could just stuff data
and call 'methods' on this module, probably without even
changing existing syntax.

Are there any arguments as to which method is better?

I would recommend a module over a Borg class simply because it's less
of a hack.

One thing that I never liked about using modules as classes was the
constant need to use the global statement when rebinding any module
level variables. For that reason, if there was a lot of rebinding, I
would rewrite the module as a singleton class. That had its own
problems; most significantly, it was a thorn in my side for
initializing things in the right order. (My current project used lots
of circular imports which made things a lot worse.)

I finally lost my patience and decided to pull that thorn out by
converting the singletons back to modules. That's when I came up with
this little decorator that obviates the need to use global statements,
plus it lets the module look and mostly act like a class.

def modmethod(func):
class modproxy(object):
__getattribute__ = func.func_globals.__getitem__
__setattr__ = func.func_globals.__setitem__
self = modproxy()
def call_with_method(*args,**kwargs):
return func(self,*args,**kwargs)
call_with_method.func_name = func.func_name
return call_with_method

This decorator means the function will get called with the module
(actually a proxy) as the first argument. That way, you can access
module-level variable exactly like you would access instance variables
in a class, i.e., via self.

I was able to convert all my singletons to modules simply by dedenting
one level, and prefixing all the methods with @modmethod. This worked
so sweetly it this is now my slam dunk recommendation for implementing
a "global singleton" class.


Carl Banks