Manager to manage diamond pattern methods

Hi, I developed easy to use way of using methods of diamond pattern methods. Would you like to add it on one of modules? If you want we or you can develop it. I am just trying to help Python community <3

from types import MethodType, FunctionType
from inspect import isclass
from functools import cache
from typing import Any,Self

class base_manager:

    def __init__(self, target : object,
                 helper_class : type) -> None:
        if not isclass(helper_class):
            raise TypeError(f"{helper_class.__name__} , this is not a class")
        self.__target: object = target
        self.__helper_class: type[Any] = helper_class

    def __enter__(self) -> Self:
        return self()
    def __call__(self) -> object:

        for obj_method in self.methods:
        return self.__target

    def methods(self) -> list[MethodType]:
        return [MethodType(method, self.__target)for method in 
    def names_and_functions(self) -> dict:

        return {key:current_atr for key in 
                if bool(current_atr := 
                and key not in object.__dict__ and 

    def __exit__(self, exc_type, exc_val, exc_tb) -> None:

        for obj_method_key in self.names_and_functions:

Why did you feel this test was necessary?

Yes, you are right sorry :pray:

No problem. And why on earth are you deleting attrs on the target in __exit__? That’s a tad, destructive. And posssibly even dangerous.

    def __exit__(self, exc_type, exc_val, exc_tb) -> None:

        for obj_method_key in self.names_and_functions:

Overall, what’s this code actually used for?

Perhaps this is just my lack of imagination and ignorance but “Diamond patterns” to my mind are a multiple inheritance pattern (I have not come across “diamond” in any other context in Python), and I can’t imagine how this code possibly helps that.

class GrandChild(ChildA, ChildB):
    def __init__(self):
    def print_name(self):
        with base_manager(self,ChildB):

maybe like this

I thought it more dynamic like more than 2

Could you please describe concertly what problem you are trying to solve? Generally, when proposing something to be added, it’s better to start with a use-case and/or problem statement instead of a solution. I have no clue when I would want to use this, and why.

I don’t see the advantage over ChildB.print_name(self) or using super, but maybe someone else understands your intent better than me.

Thanks, That is my first time sorry :pray:

Yes, you are right. I have made over engineering :frowning:

That’s fine. You’ll come out of this with a deeper understanding than
most people.

Yes. And no.

I’ve got a little context manager called stackattrs which I routinely
use in setup then shutdown stuff like this:

 with stackattrs(
     ... do stuff ...

which sets attrs on obj for the duration. Very useful in a number of
situations. Anyway, it restores the previous state of those attributes
on exit from the context. Particularly, if those attrs were not there at
the start, it removes them. (Of course, if they were there previously
with some value, that value gets restored.)

Now, I do find myself going back to the init of obj sometimes and
putting stub self.attr1 = None statements in sometimes. But often to
make linters happy.

Having the attributes gone where you’re out of the context scope can be
quite handy for discovering you’ve misused something because you get
nice loud AttributeErrors.

You can get stackattrs from my cs.context PyPI module if you want to
play with it.

1 Like