Style: global configuration data

[Alex Martelli]

"Peter Hansen" <peter at engcorp.com> wrote in message
news:3A0EB7EB.8BE2C326 at engcorp.com...
> Boudewijn Rempt wrote:
> >
> > I have been wondering for some time about the best way to offer
> > configuration data and other global resources to all modules and classes
> > in my application, other than creating a config object and passing that
> > on with every constructor.  What's the received Pythonic wisdom on this?
> >
> > I'd prefer to just have one instance of my config class, or my
repository
> > class or whatever, so if I were working in Java I'd create a singleton,
but
> > that somehow doesn't seem right for Python to me.
>
> I'm not the best one to answer this (no doubt Alex is :-), but I

I have my (strong) opinions on the design-pattern "singleton", yes
(I'm on record as stating it's the least well thought-out in the GoF
book), but they're not Python-specific.  In Python, as you suggest,
using a module rather than a class to house a single-instance group
of data is simple and effective.  If you do need to use classes (in
Python e.g. to be able to do __setattr__/__getattr__, or inherit
from a suitable metaclass to get e.g. synchronized behaviour, ...),
"featherweight objects" (with distinct identities, but shared state)
are as feasible in Python as elsewhere (or more:-) and have more
or less the usual advantages wrt the singleton-pattern -- not as huge
as, say, in COM, but roughly as large as in, e.g., C++ or Java.

(For example -- featherweight objects enable easy upgrade over
time of the "singleton" to a newer/richer/bugfixed version in a
long-running server process that can load new code dynamically;
they let you change central design so that, without change to
the client-side of the code, different parts of the system can 'see'
different versions of the 'centralized' resources; etc... 'singleton',
where the same object is referred to by all client-side code,
offers no real compensating advantages to offset these).


Alex