PEP 3133 – 역할 소개

Author:: Collin Winter <collinwinter at google.com>
Status:: Rejected
Type:: Standards Track
Requires:: 3115, 3129
Created:: 01-May-2007
Python-Version:: 3.0
Post-History:: 13-May-2007

Table of Contents

번역·라이선스 안내

이 비공식 한국어 번역은 원문 Copyright 절의 Public Domain 조건에 따라 제공합니다. 원저자와 공식 원문은 그대로 표시합니다. 수정되지 않은 기준 원문 · 공식 최신판

거부 통지

이 PEP는 PEP 3119를 보다 건전하고 미니멀한 접근 방식으로 나아가도록 하는 데 기여했습니다. 그러나 PEP 3119의 최신 버전을 고려하면 저는 그것을 훨씬 더 선호합니다. GvR.

초록

Python의 기존 객체 모델은 객체를 그 구현에 따라 구성합니다. 특히 Python과 같은 덕 타이핑 기반 언어에서는 객체를 그 부분을 어떻게 충족하는지(구현)가 아니라 더 큰 시스템에서 수행하는 부분(의도)에 따라 구성하는 것이 바람직한 경우가 많습니다. 이 PEP는 객체를 구현이 아니라 의도에 따라 구성하는 메커니즘인 역할 개념을 소개합니다.

태초에 객체가 있었습니다. 객체는 프로그래머가 함수와 상태를 결합하고, 다형성 및 상속과 같은 개념을 통해 코드 재사용성을 높일 수 있도록 했으며, 보라, 좋았습니다. 그러나 상속과 다형성만으로는 충분하지 않은 때가 왔습니다. 개와 나무가 모두 발명되면서, 우리는 더 이상 단순히 “‘짖음’을 이해하는가?”를 아는 것만으로 만족할 수 없었습니다. 이제는 주어진 객체가 “‘짖음’이 무엇을 의미한다고 생각하는지”를 알아야 했습니다.

여기서 자세히 설명하는 한 가지 해결책은 전통적인 클래스/인스턴스 시스템과 직교하면서 이를 보완하는 메커니즘인 역할입니다. 클래스가 상태와 구현을 다루는 반면, 역할 메커니즘은 주어진 클래스에 구현된 동작만을 다룹니다.

이 시스템은 원래 “traits”라고 불렸으며 Squeak Smalltalk에 구현되었습니다 [4]. 이후 Perl 6 [3]에서 사용되도록 조정되었고 그곳에서는 “roles”라고 불리며, 현재 Python 3을 위해 이 개념을 해석하는 것은 주로 여기에서 비롯되었습니다. Python 3에서는 “roles”라는 이름을 유지합니다.

한마디로 말하면, 역할은 객체가 무엇을 하는지 알려 주고 클래스는 객체가 어떻게 하는지 알려 줍니다.

이 PEP에서는 주어진 객체가 “‘짖음’에 대해 이해하는 방식”이 나무와 같은지 개와 같은지를 쉽게 판별할 수 있도록 하는 Python 3용 시스템의 개요를 설명합니다. (더 심각한 예도 있을 수 있습니다.)

구문에 관한 참고 사항

이 PEP의 구문 제안은 잠정적인 것이며 허수아비 제안으로 간주해야 합니다. 이 PEP가 의존하는 필수 요소, 즉 PEP 3115의 클래스 정의 구문과 PEP 3129의 클래스 데코레이터는 아직 형식화되는 중이며 변경될 수 있습니다. 물론 함수 이름은 장시간에 걸친 자전거 보관소 논쟁의 대상이 될 것입니다.

역할 수행

정적 역할 할당

Tree 및 Dog 클래스를 정의하는 것부터 시작합시다.

class Tree(Vegetable):

  def bark(self):
    return self.is_rough()


class Dog(Animal):

  def bark(self):
    return self.goes_ruff()

둘 다 동일한 시그니처의 bark() 메서드를 구현하지만, 실제로는 매우 다른 일을 합니다. 우리가 기대하는 바를 구별할 방법이 필요합니다. 상속과 단순한 isinstance() 테스트에 의존하면 코드 재사용이 제한되거나, 타당한지 여부와 관계없이 개와 같은 모든 클래스가 Dog에서 상속하도록 강제될 수 있습니다. 역할이 도움이 될 수 있는지 살펴봅시다.

@perform_role(Doglike)
class Dog(Animal):
  ...

@perform_role(Treelike)
class Tree(Vegetable):
  ...

@perform_role(SitThere)
class Rock(Mineral):
  ...

특정 역할 또는 여러 역할을 클래스에 연결하기 위해 PEP 3129의 클래스 데코레이터를 사용합니다. 이제 클라이언트 코드는 전달된 객체가 Doglike역할을 수행하는지 확인할 수 있으므로, Wolf, LaughingHyena 및 Aibo [1] 인스턴스도 처리할 수 있습니다.

역할은 일반 상속을 통해 조합할 수 있습니다:

@perform_role(Guard, MummysLittleDarling)
class GermanShepherd(Dog):

  def guard(self, the_precious):
    while True:
      if intruder_near(the_precious):
        self.growl()

  def get_petted(self):
    self.swallow_pride()

여기서 GermanShepherd 인스턴스는 세 가지 역할을 수행합니다. Guard 및 MummysLittleDarling은 직접 적용되고, Doglike은 Dog에서 상속됩니다.

런타임에 역할 할당

데코레이터가 제공하는 구문 설탕을 풀어 쓰면 런타임에도 역할을 할당할 수 있습니다.

가령 다른 모듈에서 Robot 클래스를 가져온다고 하겠습니다. Robot이 이미 우리가 사용하는 Guard 인터페이스를 구현한다는 것을 알고 있으므로, 경비 관련 코드에서도 잘 작동하도록 만들고 싶습니다.

>>> perform(Guard)(Robot)

이는 즉시 적용되며 모든 Robot 인스턴스에 영향을 줍니다.

역할에 관해 질문하기

로봇 군대에 자신들이 경비병이라고 알려 주었다고 해서, 가끔씩 상태를 확인하여 여전히 맡은 임무를 수행하고 있는지 확인하고 싶을 것입니다.

>>> performs(our_robot, Guard)
True

저기 있는 저 로봇은 어떻습니까?

>>> performs(that_robot_over_there, Guard)
True

performs() 함수는 주어진 객체가 주어진 역할을 수행하는지 확인할 때 사용합니다. 그러나 클래스의 인스턴스가 역할을 수행하는지 확인하는 데 사용할 수는 없습니다:

>>> performs(Robot, Guard)
False

이는 Robot 클래스와 Robot 인스턴스가 서로 바꿔 사용될 수 없기 때문입니다.

새로운 역할 정의하기

빈 역할

역할은 일반 클래스와 같은 방식으로 정의하지만 Role 메타클래스를 사용합니다.

class Doglike(metaclass=Role):
  ...

메타클래스는 5가 int이고 tuple이 type인 것과 같은 방식으로 Doglike가 Role임을 나타내는 데 사용됩니다.

상속을 통한 역할 조합

역할은 다른 역할을 상속할 수 있으며, 이렇게 하면 역할이 조합됩니다. 여기서 Dog 인스턴스는 Doglike 및 FourLegs 역할을 모두 수행합니다.

class FourLegs(metaclass=Role):
  pass

class Doglike(FourLegs, Carnivor):
  pass

@perform_role(Doglike)
class Dog(Mammal):
  pass

구체적인 메서드 요구하기

지금까지는 빈 역할만 정의했으며, 그다지 유용하지 않습니다. 이제 Doglike 역할을 수행한다고 주장하는 모든 클래스가 bark() 메서드를 정의하도록 요구합시다:

class Doglike(FourLegs):

  def bark(self):
    pass

메서드를 “추상”으로 표시하기 위한 데코레이터는 필요하지 않으며, 해당 메서드는 절대 호출되지 않으므로 그 안에 포함된 코드(있다면)는 무엇이든 관계없습니다. 역할은 추상 메서드만 제공하며, 구체적인 기본 구현은 믹스인과 같이 더 적합한 다른 메커니즘에 맡깁니다.

역할을 정의하고 클래스가 해당 역할을 수행한다고 주장한 후에는 그 주장을 검증하는 것이 필수적입니다. 여기서 프로그래머는 역할에 필요한 메서드 중 하나의 철자를 잘못 입력했습니다.

@perform_role(FourLegs)
class Horse(Mammal):

  def run_like_teh_wind(self)
    ...

이로 인해 역할 시스템은 run_like_the_wind() 메서드가 누락되었다고 알리는 예외를 발생시킵니다. 역할 시스템은 클래스가 특정 역할을 수행하는 것으로 표시되는 즉시 이러한 검사를 수행합니다.

구체적인 메서드는 역할이 요구하는 시그니처와 정확히 일치해야 합니다. 여기서 bark()의 구체적인 버전을 정의하여 역할을 충족하려고 했지만, 약간 맞지 않습니다.

@perform_role(Doglike)
class Coyote(Mammal):

  def bark(self, target=moon):
    pass

이 메서드의 시그니처가 Doglike 역할이 예상하던 것과 정확히 일치하지 않으므로 역할 시스템이 약간 발끈할 것입니다.

메커니즘

다음은 Python에서 역할을 표현하는 방법에 대한 임시 제안입니다. 여기의 예제는 Python 인터프리터를 변경하지 않고 역할 메커니즘을 구현할 수 있도록 표현되어 있습니다. (예제는 Curtis Poe의 Perl 6 역할에 관한 글 [2]에서 각색했습니다.)

정적 클래스 역할 할당
```
@perform_role(Thieving)
class Elf(Character):
  ...
```
perform_role()은 여러 인자를 허용하므로 다음과 같이 작성하는 것도 올바릅니다.
```
@perform_role(Thieving, Spying, Archer)
class Elf(Character):
  ...
```
이제 Elf 클래스는 Thieving, Spying, Archer 역할을 모두 수행합니다.
인스턴스 조회
```
if performs(my_elf, Thieving):
  ...
```
performs()의 두 번째 인자는 __contains__() 메서드를 가진 어떤 것이든 될 수 있으므로 다음과 같이 작성하는 것이 올바릅니다.
```
if performs(my_elf, set([Thieving, Spying, BoyScout])):
  ...
```
isinstance()와 마찬가지로, 표현식이 참이 되려면 객체가 집합에 포함된 역할 중 하나만 수행하면 됩니다.

추상 베이스 클래스와의 관계

이 PEP의 초기 초안 [5]에서는 역할이 PEP 3119에서 제안된 추상 베이스 클래스와 경쟁하는 것으로 구상했습니다. 추가적인 논의와 숙고를 거쳐 다음과 같은 타협안과 책임 및 사용 사례의 위임이 마련되었습니다.

역할은 객체의 의미론과 추상적 능력을 나타내는 방법을 제공합니다. 역할은 추상 메서드를 정의할 수 있지만, 이는 특정한 의미론 집합에 접근하는 인터페이스를 구분하기 위한 방법일 뿐입니다. Ordering 역할은 어떤 순서 연산자 집합이 정의되어 있어야 한다고 요구할 수 있습니다.
```
class Ordering(metaclass=Role):
  def __ge__(self, other):
    pass

  def __le__(self, other):
    pass

  def __ne__(self, other):
    pass

  # ...and so on
```
이러한 방식으로 특정 구현을 제약하거나 염려하지 않고 더 큰 시스템 안에서 객체의 역할이나 기능을 나타낼 수 있습니다.
반면 추상 베이스 클래스는 공통적이고 분리된 구현 단위를 재사용하는 방법입니다. 예를 들어, 다른 연산자를 바탕으로 여러 순서 연산자를 구현하는 OrderingMixin을 정의할 수 있습니다.
```
class OrderingMixin:
  def __ge__(self, other):
    return self > other or self == other

  def __le__(self, other):
    return self < other or self == other

  def __ne__(self, other):
    return not self == other

  # ...and so on
```
이 추상 베이스 클래스, 더 정확히는 구체 믹스인을 사용하면 프로그래머가 제한된 연산자 집합을 정의하고 믹스인이 사실상 나머지 연산자를 “도출”하도록 할 수 있습니다.

이 두 직교 시스템을 결합하면 다음 두 가지를 모두 할 수 있습니다. a) 기능을 제공하고, b) 소비자 시스템에 이 기능의 존재와 사용 가능성을 알릴 수 있습니다. 기능의 존재와 사용 가능성을 알릴 수 있습니다. 예를 들어 위의 OrderingMixin 클래스는 Ordering 역할에 표현된 인터페이스와 의미론을 충족하므로, 믹스인이 해당 역할을 수행한다고 말합니다.

@perform_role(Ordering)
class OrderingMixin:
  def __ge__(self, other):
    return self > other or self == other

  def __le__(self, other):
    return self < other or self == other

  def __ne__(self, other):
    return not self == other

  # ...and so on

이제 믹스인을 사용하는 모든 클래스는 자동으로, 즉 프로그래머의 추가 작업 없이 Ordering 역할을 수행하는 것으로 태그됩니다.

관심사를 서로 구별되는 두 개의 직교 시스템으로 분리하는 것이 바람직한 이유는 각각을 별도로 사용할 수 있기 때문입니다. 예를 들어 컨테이너가 해시 값을 결정할 때 자신의 내용을 고려한다는 것을 나타내는 RecursiveHash 역할을 제공하는 서드파티 패키지를 생각해 보십시오. Python의 내장 tuple 및 frozenset 클래스는 이 의미론을 따르므로 RecursiveHash 역할을 이들에 적용할 수 있습니다.

>>> perform_role(RecursiveHash)(tuple)
>>> perform_role(RecursiveHash)(frozenset)

이제 RecursiveHash 객체를 사용하는 모든 코드는 튜플과 프로즌셋도 사용할 수 있게 됩니다.

미해결 문제

인스턴스가 자신의 클래스와 다른 역할을 수행하도록 허용하기

Perl 6에서는 인스턴스가 해당 클래스와 다른 역할을 수행할 수 있습니다. 이러한 변경 사항은 단일 인스턴스에 국한되며 해당 클래스의 다른 인스턴스에는 영향을 미치지 않습니다. 예를 들면 다음과 같습니다.

my_elf = Elf()
my_elf.goes_on_quest()
my_elf.becomes_evil()
now_performs(my_elf, Thieving) # Only this one elf is a thief
my_elf.steals(["purses", "candy", "kisses"])

Perl 6에서는 인스턴스의 원래 부모 클래스를 상속하고 추가 역할을 수행하는 익명 클래스를 생성하여 이를 수행합니다. Python 3에서도 가능하지만, 그것이 바람직한지는 여전히 별개의 문제입니다.

물론 이 기능을 포함하면 Python으로 Charles Dickens의 작품을 표현하기가 훨씬 쉬워집니다.

>>> from literature import role, BildungsRoman
>>> from dickens import Urchin, Gentleman
>>>
>>> with BildungsRoman() as OliverTwist:
...   mr_brownlow = Gentleman()
...   oliver, artful_dodger = Urchin(), Urchin()
...   now_performs(artful_dodger, [role.Thief, role.Scoundrel])
...
...   oliver.has_adventures_with(ArtfulDodger)
...   mr_brownlow.adopt_orphan(oliver)
...   now_performs(oliver, role.RichWard)

속성 요구

Neal Norwitz는 메서드를 요구할 때 사용하는 것과 동일한 메커니즘을 사용하여 속성의 존재를 단언할 수 있는 기능을 요청했습니다. 역할은 클래스 정의 시점에 적용되고 대부분의 속성은 클래스의 __init__() 메서드에 의해 런타임에 정의되므로, 메서드와 동시에 속성을 검사할 좋은 방법은 없어 보입니다.

문서화 목적으로만이라도 강제되지 않는 속성을 역할 정의에 포함하는 것이 여전히 바람직할 수 있습니다.

역할의 역할

제안된 의미론에 따르면 역할이 자체 역할을 갖는 것이 가능합니다.

@perform_role(Y)
class X(metaclass=Role):
  ...

이것이 가능하기는 하지만 역할은 일반적으로 인스턴스화되지 않으므로 의미가 없습니다. 이 표현에 의미를 부여하는 것에 관해 오프라인에서 논의된 적은 있지만, 지금까지 좋은 아이디어는 나오지 않았습니다.

class_performs()

현재는 클래스에 해당 클래스의 인스턴스가 주어진 역할을 수행하는지 물을 수 없습니다. 다음과 같은 performs()의 유사 기능을 제공하는 것이 바람직할 수 있습니다.

>>> isinstance(my_dwarf, Dwarf)
True
>>> performs(my_dwarf, Surly)
True
>>> performs(Dwarf, Surly)
False
>>> class_performs(Dwarf, Surly)
True

구문 지원

이 PEP에 제시된 표현은 역할 시스템을 독립형 패키지로 제공할 수 있도록 설계되었지만, 역할을 정의하고 할당하며 질의하기 위한 특수 구문을 추가하는 것이 바람직할 수 있습니다. 한 가지 예로 역할 키워드를 들 수 있으며, 이는 다음으로 변환됩니다.

class MyRole(metaclass=Role):
  ...

다음으로

role MyRole:
  ...

역할 할당은 PEP 3115에서 제안된 클래스 정의 인자를 활용할 수 있습니다.

class MyClass(performs=MyRole):
  ...

Python 개선 제안 한국어 번역

PEP 3133 – 역할 소개

거부 통지

초록

근거

구문에 관한 참고 사항

역할 수행

정적 역할 할당

런타임에 역할 할당

역할에 관해 질문하기

새로운 역할 정의하기

빈 역할

상속을 통한 역할 조합

구체적인 메서드 요구하기

메커니즘

추상 베이스 클래스와의 관계

미해결 문제

인스턴스가 자신의 클래스와 다른 역할을 수행하도록 허용하기

속성 요구

역할의 역할

class_performs()

더 보기 좋은 동적 역할 할당

구문 지원

구현

감사의 글

참고 문헌

Copyright