I use a singleton class called Config (some times I use it as a Cache too)

Singleton pattern: https://www.geeksforgeeks.org/singleton-pattern-in-python-a-complete-guide/

Config class using Singleton pattern: https://charlesreid1.github.io/a-singleton-configuration-class-in-python.html

In programming, people often talk in absolutes, but there‘s often exceptions to these rules, depending on situation and depending on the programming language. In Python, things like dependency injection don‘t make a lot of sense, because it just isn‘t needed. It‘s a pattern extensively used in other languages like Java, but only because Java has limitations that don‘t exist in Python. Trying to use Java patterns into Python just because it „sounds right“ or because it‘s a „best practice“ in another language does not make your code actually good python. It‘s not necessarily bad, but more complicated than it needs to be, and simpler is usually better if it yields the same end result. Don‘t overthink it.

You say global variables are a very bad thing, but do you know why that is? People often hear about things like that but don‘t learn about the „why“, which hinders you from properly thinking about your code.

Global variables are a bad thing because it is very hard to reason about their state at certain points in your programs execution. But what if your variable never changes, like a constant? Then you don‘t really have that problem. So an immutable config read in at startup and accessed by multiple classes/functions works just fine. You could also have a function that, when you run it the first time loads the config, „caches“ it in a global variable and then in subsequent calls just returns the global config.

To ensure immutability, you can use a frozen dataclass or something with validation built in like frozen pydantic models.

If you think you need mutability, think again. It’s better to put whatever you need to mutate outside of the global Config class, and then initialize that with the config. But keep the config itself read-only.

Imo for configs it's fine having a config file that's accessed via static methods or a singleton. I'm open to any good arguments against that practice though.

Why every class creates its own logger? That might make sense, but looks suspicious

Use global imported variables for configs.

You could use dependency injection to set up config once and inject it where needed. at work we use https://pypi.org/project/inject/ . It has its quirks with the autoinjection, you sometimes need to tell it explicitly which parameters to inject, but works great overall.

You need traitlets yesterday. It comes with a logging attribute and has extensive support for configuration - via command-line, or config files or python oop.

• Parse the config in main
• create and wire your objects passing any necessary values
• ???

It's always interesting to read about best practices that advise against using a certain feature of a platform. If that feature is so bad, why was it added as a feature in the first place?

If the feature best fits your use case, use it with the understanding of the reasons the best practice advises against it and decide for yourself if you can accept and manage those concerns.

Depending on what config data you need it might be a good idea to use environment variables. If all you need are server locations and credentials then environment variables are likely your best bet.

If you need fancy JSON or something else, global variables are nice.

You have the right idea.

One approach is to store cfg in json w/a class that reads that json. Remember to validate the json vs schema first!

That cfg class should also set env vars so that you don’t need to rely on env vars being correctly set by an invoking shell (json to rescue).

The cfg object instance becomes a parameter to class constructors or module functions.

If the idea of passing around a cfg instance is appalling, then hello global / singleton pattern!