I'm working on a Python application in which there are two Singleton classes: App and Configuration.

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()

Now, 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

Where 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:

1. Using the class Singleton
2. 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?