I'm working on a Python application in which there are two Singleton classes:
The former seems straight forward, only ever instantiate one
App instance; the latter seems controversial.
From the searches I've done, I need
Configuration to be accessible from other modules that update the application's configuration file (and subsequently update the application). To do this, I've designed my class as a Singleton by controlling instantiation through its metaclasses
__call__ method. To access the instance, in any module I do the following:
from app.config import Configuration class Foo: def __init__(self, *args, **kwargs): self.config = Configuration()
Foo is some feature beloning to
App, I could've just as easily done:
from app import App class Foo: def __init__(self, *args, **kwargs): self.config = App().configuration
App() returns the application Singleton and
.configuration was an attribute where the
Configuration was first instantiated. Further searching shows I could even use the
app.config module as a Singleton, since Python only loads modules once. So regardless of defining a class as a Singleton or treating the module as a Singleton, the Singleton Pattern remains.
So what's wrong with either of these:
- Using the class Singleton
- Treating the module as a Singleton
In any case, I need a single configuration for the entire application. Creating multiple instances would lead to potential race conditions, so this seems like a smart way to handle it. Further, it seems extensible for features such as logging, right?