Recursive assignment of fields in settings.py to the app.settings object

[RadarJam]

New feature to support Dot notation when working with settings.py.

Dot notation can be used to fetch keys/values from dictionaries specifed in settings.py , see code snippets below.

# settings.py
d = {
    "k1": "v1",
    "k2": "v2",
    "k3":{"a":"a","b":"b"}
}

# intents.py
class MyIntent(Intent):
    lead = ('Hello', 'Hi')

    def respond(self, message: Message) -> Reply | ReplyStream:
        print(app.settings.d.k3.a)
        print(app.settings.d["k3"]["a"])
        print(app.settings.d.k3["a"])

Closes #76

[dotchetter]

Thank you for this contribution!
I have some concerns I've mentioned in comments in the PR, as I think we can achieve the same effect with a lot less code; by instead re-using the Settings class and leveraging a class method or alike, which could return an instance of self, since it already supports dot notation. This would cause all dicts and sub-dicts being assigned to the Settings object to be cast to an instance of self, with all the benefit it brings.

[dotchetter]

Please use setUp hook in tests instead of overriding __init__. The setUp hook is left unimplemented for these suites to implement them for this purpose.

[dotchetter]

I think this file is redundant, and the relative import can be troublesome in a shipped package due to its relativity. Can the mockup dict object be placed in the test suite instead, such as in setUp, or as a property in the test suite?

[dotchetter]

I have some thoughts about this method.

1. Is there a specific reason as to why __ is used? I don't think it should be named with two leading underscores, since name mangling here is unlikely to be utilized.
   I would prefer a single _ in the method and attribute name.

2. Is dumping the entire dictionary to a string and then reloading it again in to the custom dict class CustomUserDict really necessary? Can it not be done with a cast?

3. I can't see self being used here. I think this should be a class method in the CustomUserDict instead, returning an instance of itself.

4. Method names should not contain digits

[dotchetter]

I think this class is redundant, since we already have the Settings class which could implement this API instead.. I'd prefer if the Settings class would handle a recursive assignment of self for all sub-dictionaries, instead of the first level being a Settings object and all subnodes being of a different type, for no apparent reason.

[dotchetter]

According to PEP-8, single _ hint to a private method - unless mangling is required, but it' highly unlikely to be needed here.

[RadarJam]

Updated PR, I managed to fix most of the requested changes except item#2 on: #78 (comment)

[dotchetter]

Looks better, except for the memory leak in Settings.__init__ and the _ _ naming in __set_attr, a single underscore is sufficient (name mangling is not required)

[dotchetter]

⚠️ This will cause a memory leak ⚠️

The problem is that in Python, default keyword arguments are parsed once, not for each call.
The argument default dictionary={} statement, is creating one dictionary used over and over again for every call. The same is true for anything non-primitive. It could cause serious implications where multiple instances of this class will share the same dictionary memory reference.

An example

If you create multiple instances of a class with this syntax, this is the result of the leak:

class A:
    def __init__(self, dictionary={})
        self.dictionary = dictionary

first = A()
second = A()

first.dictionary["foo"] = "bar"

# leak in plain sight
print(second.dictionary["foo"]
>>> "bar"

# cross-mutation
second.dictionary["foo"] = None

print(first.dictionary)
>>> None

print(first.dictionary is second.dictionary)
>>> True  # Not what we want :) 

For an example, see this stack overflow post

To fix this, use the default argument None as:

def foo(data=None):
   if data is None:
      data = {}  # Created in the function scope, fixes the issue