this post was submitted on 07 Jul 2023
12 points (100.0% liked)

Python

6470 readers
19 users here now

Welcome to the Python community on the programming.dev Lemmy instance!

📅 Events

PastNovember 2023

October 2023

July 2023

August 2023

September 2023

🐍 Python project:
💓 Python Community:
✨ Python Ecosystem:
🌌 Fediverse
Communities
Projects
Feeds

founded 2 years ago
MODERATORS
 

I am writing an object-oriented app to help our developers manage some cloud systems. I'd like to make the configuration information available to all the classes, but I'm not sure of a good way to do that. Everything I can think of seems to fall under the category of "global variables" which as far as I know is a Very Bad Thing.

I already have a logging Mixin class that enables logging for every class that inherits it, and I was wondering if that's the right way to approach the configuration data:

class LoggingMixin:
    @classmethod
    @property
    def log(cls):
        return logging.getLogger(cls.__name__)

class TestClassA(LoggingMixin):
    def testmethod1(self):
        self.log.debug("debug message from test class A")

if __name__ == "__main__":
    logging.basicConfig(
        format="{created:<f} {levelname:>5s} {name}.{funcName:>8s} |{message}|",
        level=logging.DEBUG,
        style="{",
    )

    a = TestClassA()
    a.testmethod1()

Outputs (in case you are curious)

1688494741.449282 DEBUG TestClassA.testmethod1 |debug message from test class A|

What's a good way of making data from a class available to all classes/objects? It wouldn't be static, it'd be combined from a JSON file and any command line parameters.

If I copied the example above but changed it to a ConfigMixin, would that work? With the logging example, each class creates its own logger object when it first calls self.log.debug, so that might not work because each object needs to get the same config data.

Is there a pattern or other design that could help? How do you make configuration data available to your whole app? Do you have a config object that can get/set values and saves to disk, etc?

Thank you for reading, my apologies for poorly worded questions.

you are viewing a single comment's thread
view the rest of the comments
[–] [email protected] 2 points 1 year ago* (last edited 1 year ago) (1 children)

Agree.

Globals are a big problem in multithreaded / shared memory envs even when designs have a clear “here is where globals are set, and this is when”.

If single threaded, it’s a style choice but can lead to subtle bugs when the global keyword is forgotten - for ex, a function is accessing a global variable without the global keyword.

Then, later on, a developer updates the function to store a result in the variable, which converts the variable to local. Suddenly code which has been working “for years” may suddenly be askew and it’s not necessarily clear why (a good reason to lint code imo).

So if using global, be diligent in identifying them as such! Have a style standard (g_ to help.

[–] [email protected] 2 points 1 year ago (1 children)

This is probably a good point to add that I do try to generally avoid globals as well. I am a fan of limiting mutable state in general. But for constants (whether they are hard coded in the source code or read from a file doesn’t really matter to me) they make sense.

And just to emphasize again, if you are building an App with user settings that may be changed during runtime, the „global constant config“ pattern does not apply. It only really works for static configuration read at startup.

For a mutable runtime config, you really have to think hard about when it is allowed to change and how these changes are propagated throughout your app, otherwise you may end up with inconsistent behavior where part of your program still uses the old values. There’s many ways to solve this depending on the programs architecture and requirements though.

[–] [email protected] 2 points 1 year ago

Ah. Great point. In a threaded environment with dynamic configuration, paying attention to the exact use case is essential! Hidden constraints and unknown requirements might undo generic advice. That said, publisher/subscriber is a decent async pattern!