Mixin의 불확실한 참조를 금지하는 것에 대해

[cbscsm]

저희 코드에는 다양한 Mixin이 쓰이고 있는데, 그 중에는 다음과 같은 불확실한 참조를 포함하는 경우가 있습니다.

• Mixin의 MRO에서 찾을 수 없는 attribute에 대한 self 참조(자식이 가지고 있기를 기대 - 부모가 자식에 의존하는 잘못된 상속 관계)
• Mixin 부모의 MRO에서 찾을 수 없는 attribute에 대한 super 참조(자식의 MRO에서 Mixin 이후에 나타나기를 기대)

class Parent:
    def parent(self):
        print('parent')


class Mixin:
    def mixin(self):
        print('mixin')
        self.child()  # 경고
        super().parent()  # 경고


class Child1(Mixin, Parent):
    def child(self):
        print('child1')


class Child2(Mixin, Parent):
    pass


Child1().mixin()  # mixin child1 parent
Child2().mixin()  # 메서드 호출 시점 AttributeError

위 예시 코드는 이 두 가지 문제를 모두 담고 있습니다.
런타임에는 잘 동작하지만, IDE는 이에 대해 경고를 표시합니다.
왜냐하면, Mixin 입장에서는,

• 자신을 상속하는 클래스가 child 메서드를 정의하며,
• 자신 이후에 Parent 클래스도 상속해주길 믿고 기대할 수 밖에 없고,

만약 자식 클래스가 잘못된 상속 관계를 가지더라도 정적으로 이를 판단할 수 없어 런타임 에러의 발생을 막을 수 없기 때문입니다.
또한 Mixin 클래스의 자체 인스턴스화도 막을 수 없습니다.

이는 다음과 같이 깔끔하게 해결할 수 있습니다.

• 자식이 가져야하는 attribute를 abc.abstractmethod로 선언
• super에서 기대하는 attribute는, 자신도 그 클래스를 상속

import abc


class Parent:
    def parent(self):
        print('parent')


class Mixin(Parent, abc.ABC):
    @abc.abstractmethod
    def child(self):
        pass

    def mixin(self):
        print('mixin')
        self.child()
        super().parent()


class Child1(Mixin, Parent):
    def child(self):
        print('child1')


class Child2(Mixin, Parent):  # Class Child2 must implement all abstract methods 경고 발생
    pass


Child1().mixin()  # mixin child1 parent
Child2().mixin()  # 생성 시점 TypeError

이제 경고가 Mixin 클래스가 아니라, 실제로 잘못을 한 Child2 클래스에서 발생합니다.
그리고 Child2가 생성되는 시점에서 에러가 발생합니다. 기존에는 생성은 잘 되고, 메서드 호출에서 에러가 발생했습니다.
보다 이른 시점에 에러가 발생하기 때문에 더 낫습니다.

두 번째 super에 대한 부분에서는, Mixin이 부르는 super의 대상이 그 때 그때 달라져야할 때 문제가 될 수 있습니다. 그럴 때에는, 동작을 가지지 않는, 최상위 베이스 클래스를 상속하면 됩니다(없으면 만들어야 합니다).

import abc


class BaseParent(abc.ABC):
    @abc.abstractmethod
    def parent(self):
        pass


class Parent1(BaseParent):
    def parent(self):
        print('parent1')


class Parent2(BaseParent):
    def parent(self):
        print('parent2')


class Mixin(BaseParent, abc.ABC):
    @abc.abstractmethod
    def child(self):
        pass

    def mixin(self):
        print('mixin')
        self.child()
        super().parent()


class Child1(Mixin, Parent1):
    def child(self):
        print('child1')


class Child2(Mixin, Parent2):
    def child(self):
        print('child2')


class Child3(Mixin):  # Class Child3 must implement all abstract methods 경고
    def child(self):
        print('child3')


Child1().mixin()  # mixin child1 parent1
Child2().mixin()  # mixin child2 parent2
Child3()  # 생성 시점 TypeError 발생

올바른 상속 관계를 가지지 않는 Child3에서도 경고가 나타남을 볼 수 있습니다.
역시 이를 무시하고 생성하면 생성 시점에 에러가 발생합니다.

---

위 방법들을 활용해서, Mixin 클래스에서 불확실한 참조를 하지 않도록 할 수 있으므로,
Mixin 클래스에서 불확실한 참조를 금지하는 정책을 제안합니다.

혹시 위 경우 외에, 어쩔 수 없이 불확실한 참조가 필요한 경우가 있거나,
더 좋은 방법이 있다면 의견 부탁드립니다.

[Kirade]

저는 믹스인의 불확실한 참조로 발생하는 여러 문제를 방지하기 위해 상속을 통한 힌트를 주는방식에 동의하지 않습니다.

제가 보는 파이썬 믹스인은 '어떤 클래스에 추가적인 기능을 제공하기 위한 기능을 담고있는 클래스' 입니다.
그리고 믹스인이 사용되는 것이 하나의 공통 부모를 가진 클래스들끼리만 활용되어야 한다는 제약은 특별히 없다고 생각합니다.

위의 예시 코드에서는 믹스인을 사용하는 클래스들이 하나의 부모로부터 파생된 클래스들에 믹스인이 붙는것으로 보이는데요.
만약 믹스인을 활용하는 클래스가 여러개이고 서로 다른 기능을 하는 부모 클래스를 각자 상속한 경우에는 상속으로 해결하기 까다로울것 같습니다.
두 부모에 각각 동일한 동작을 하는 믹스인을 별개로 만들어 낼 수 있겠지만 중복인 코드를 만들어내기 때문에 비효율적일 것입니다.

서로 다른 두 클래스가 동일한 동작을 원하는 경우, 믹스인에 정의된 함수 규칙에 따라 클래스들을 구현하게 되면 원하는 기능을 다형적으로 동작하게 할 수 있을듯합니다. 예를들면 다음과 같습니다.

class ParentA:
    def do_a(self):
        pass

class ParentB:
    def do_b(self):
        pass

class LogMixin:
    def log(self):
        logger = self.get_logger()
        logger.info('로깅')

class A(LogMixin, ParentA):
    def get_logger(self):
        return logger_from_A


class B(LogMixin, parentB):
    def get_logger(self):
        return logger_from_B

또한 특별히 믹스인에서 발생하는 경고와, 런타임 에러로 인해 중요한 문제가 발생한 경험이 없었습니다.
그래서 위의 상속 구조 혹은 추상 메서드를 생성하는 방식이 개발 속도를 낮추거나 설계 복잡도가 증가하는 방향이지는 않을까 생각했습니다.

저희가 사용중인 몇몇 오픈소스 레퍼런스를 찾아보았는데요. Django, DRF, Werkzeug 등의 믹스인에서도 불확실한 참조가 그대로 사용되는것 같습니다.

[cbscsm]

파이썬의 다중상속과 MRO 관점에서 본다면, 위 본문은 아래와 같은 제약을 하지 않습니다.

그리고 믹스인이 사용되는 것이 하나의 공통 부모를 가진 클래스들끼리만 활용되어야 한다는 제약은 특별히 없다고 생각합니다.

본문에서 제시한 믹스인 정의 규칙에서는, 믹스인을 사용하는 클래스들이 공통의 부모를 가져야할 필요는 없습니다.
"이러한 형태를 가진 클래스는 누구나 이 믹스인을 쓸 수 있다"라는 느낌으로 믹스인의 프로토콜을 정의한다고 보면 좋을 것 같습니다.
이는 typing 모듈의 프로토콜이 제공하는 정적 덕 타이핑의 기능과 유사합니다.

다양한 상속관계에서의 사용성을 생각해볼 때 오히려 불확실한 참조를 하는 경우에는
믹스인의 모든 메서드 구현 내부를 들여다보고 사용법을 검토해야한다는 단점이 있습니다.

파이썬 표준 라이브러리인 collections.abc 에서는
본문에서 제안하는 것과 같은 형태로 믹스인을 제공하고 있기 때문에 편리하게 사용할 수 있습니다.

---

작성주신 예시는 본문의 첫 번째 문제에 해당하므로, 본문 내용에 따라
별도 상속관계 없이 아래처럼 수정해주면 불확실한 참조가 일어나지 않습니다.
"믹스인을 활용하기 위해 필요한 메서드"를 명시적으로 적어주는 것이, 구조가 복잡해지는 것이라고 생각되진 않습니다.

class LogMixin(abc.ABC):
    @abc.abstractmethod
    def get_logger(self):
        pass

    def log(self):
        logger = self.get_logger()
        logger.info('로깅')

LogMixin을 활용하는 쪽에서, 자신이 이 믹스인을 활용하기 위해 무엇을 해야하는지
명확하게 알 수 있으므로, 가독성과 개발 생산성이 향상된다고 생각합니다.

말씀주신 Django, DRF, Werkzeug 등은 상대적으로 오래된 라이브러리들이기 때문에
설계 차원에서 현대적인 Pythonic 개념이 적용되지 않았을 수 있다고 생각합니다.

이런 규칙을 따른다면 믹스인을 작성할때에는 다소 번거로울 수 있겠지만,
믹스인을 읽고 파악하는 사람이나, 사용하는 사람에게 주는 이점이 훨씬 크다고 생각합니다.
특히, 믹스인처럼 재활용을 목적으로 만든 코드는 작성하는 빈도보다 읽히는 빈도가 높기 때문에도 그렇습니다.

---

다만, 믹스인이 사용하는 참조가, MRO상 믹스인보다 뒤에 있을 때에는 믹스인에서 직접 abstractmethod를 사용하는 데 문제가 있네요 ㅠ
이 경우에는 공통 조상에서 abstractmethod로 선언하거나, Mixin이 구현체보다 뒤에 있어야 하는데, 더 좋은 방법이 있을 지 알아보겠습니다.

[Kirade]

믹스인의 프로토콜을 정의해서 활용하려는 사람이 쉽게 이해할 수 있게 만드는 부분은 좋은것 같습니다.
아래 abc 를 활용해서 get_logger 를 정의해주신 방식처럼요.

[Kirade]

아 그리고 혹시 현대적인 pythonic 개념과 관련된 내용을 살펴볼 수 있는 레퍼런스가 있을까요?

[cbscsm]

아 그리고 혹시 현대적인 pythonic 개념과 관련된 내용을 살펴볼 수 있는 레퍼런스가 있을까요?

따로 레퍼런스를 찾지는 못했습니다.
파이썬의 최근 업데이트 방향과 기조가,
기존의 유연함과 심플함을 유지하면서도 견고한 프로그램을 구성하는 것을 추구한다고 생각했습니다.

[Kirade]

업데이트 방향을 바탕으로 추론해내신것이군요.
저도 한 번 그 흐름을 잘 살펴보아야겠네요!

[cbscsm]

재영님 말씀을 듣고 생각해보니, 다음과 같은 경우에는 적용이 어려울 것 같습니다.

• 메타클래스 충돌로 ABC를 사용할 수 없는 경우
• Mixin의 required method가 Mixin 보다 MRO 상 뒤쪽에 있는 클래스에서 구현되는 경우
  • 이 경우는 Mixin을 더 뒤에서 상속하면 되긴 합니다(collections.abc의 방식).

그래서 아예 불확실한 참조를 금지할 수는 없을 것 같고, 타입 힌트처럼
ABC 적용이 가능한 상황에서 적용 전후 득실에 따라서 판단하에 적용하는 것으로 바꾸어 제안합니다.

• (기존에 이미 ABC가 있거나, 구조가 단순하여) 간단하게 적용할 수 있거나
• 적용하지 않았을 때 가독성에 크게 문제가 있는 경우

[Kirade]

타입힌트처럼 득실 판단하에 적용하는 방법에 어느정도 동의합니다.
코드 작성자의 판단 하에 선택적으로 활용할 수 있으면 좋을것 같아요.