0

I want to define a decorator (let's name it subcollection) that behaves like this:

class ParentClass:
    name = None

    def __init__(self, name=None):
        self.name = name

    @subcollection
    class ChildClass:
        def greet(self):
            print(f'Hello from {self.outter.name}')

parent_class = ParentClass('Mahdi')
child_class = parent_class.ChildClass()
assert child_class.greet() == 'Hello from Mahdi'

I'm trying to achieve a complicated inheritance in python that confused me. This is needed to create a nested unstructured ORM.

I probably could do this with factory functions, but I'm wondering if there is any workaround to pass the parent_class instance at the time of the child_class creation with decorators?!

Mahdi Jadaliha
  • 1,947
  • 1
  • 14
  • 22
  • This proposed decorator would hide the fact that the constructor for an **instance** of `ChildClass` would still need to pass a reference to an **instance** of `ParentClass`, and not to mention the ORM solution that you might be using (e.g. `SQLAlchemy`?) might not like this particular construct as the proposed `subcollection` class decorator will need to make certain adjustments to the underlying class. Just go solve the problem at the ORM level first, and don't try to invent a solution that might not even fit the problem. – metatoaster Feb 05 '23 at 02:10
  • Thanks, @metatoaster, for the quick reply. I know anything could go wrong with what I want to do here. I work with unstructured databases, and changing the class on the fly is fine for my use case. Even though I cannot show the benefit of such a design in a small example here, accept from me that passing the parent instance to the child instance could be helpful sometimes, and if you could do this in the decorator, the code would look more elegant. – Mahdi Jadaliha Feb 05 '23 at 02:20
  • about "invent a solution that might not even fit the problem", If I don't want to invent I use ChatGPT not StackOverflow for my questions. :D – Mahdi Jadaliha Feb 05 '23 at 02:24
  • This fundamentally makes no sense in terms of inheritance. If `Child` were to inherit from `Parent`, that inheritance would obviously include all attributes of `Parent` (otherwise what does "inheritance" even mean?). A nested class is just an attribute of its outer class, meaning `Child` would inherit `Parent.Child` as an attribute as well, which is... itself? So `Parent.Child` is `Parent.Child.Child` is `Parent.Child.Child.Child` etc. I wonder where you are going with this. – Daniil Fajnberg Feb 05 '23 at 11:42
  • @DaniilFajnberg, whenever you define a method inside a class, that method has access to `self` (parent), but when you define an inner class in parent class, that does not have `self` referring to parent. That is what I want. If it makes sense for methods, it should make sense for the inner class. Don't you think so? Otherwise, what is the use of inner class anyway? – Mahdi Jadaliha Feb 05 '23 at 13:27
  • No, it does not. A class defined inside the body of another class does not imply any inheritance relationship whatsoever. In fact, the only relationship to speak of is that of namespaces, meaning the inner class is only accessible in global scope via its outer class. This is why your naming Parent/Child is misleading because it implies inheritance. Aside from that, `self` still refers to the instance of the _specific_ class. That will not change. The best we could do is introduce a separate attribute of the inner class that refers to the outer. – Daniil Fajnberg Feb 05 '23 at 19:40
  • @DaniilFajnberg, I like the suggestion you made. I changed the `self.name` to `self.outter.name` . – Mahdi Jadaliha Feb 05 '23 at 22:02
  • OK, the problem you pose is actually quite interesting. I decided to reformulate your question myself in a clearer and more generic way and answer it there. I think that way it will be more helpful to other readers. https://stackoverflow.com/q/75361137/19770795 – Daniil Fajnberg Feb 06 '23 at 12:13

0 Answers0