PEP 253 – 내장 타입의 서브타이핑

Author:

Guido van Rossum <guido at python.org>

Status:

Final

Type:

Standards Track

Created:

14-May-2001

Python-Version:

2.2

Post-History:

---

Table of Contents

• 초록
• 서론
• 메타타입에 관하여
• 타입을 인스턴스의 팩토리로 만들기
• 서브타이핑을 위한 타입 준비
• C에서 내장 타입의 서브타입 만들기
• Python에서의 하위 형식화
• 다중 상속
• MRO: 메서드 결정 순서 (조회 규칙)
• XXX 수행할 작업
  • 미해결 문제
• 구현
• 참고 문헌
• Copyright

번역·라이선스 안내

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

초록

이 PEP는 C와 Python에서 내장 타입의 서브타입을 생성할 수 있도록 타입 객체 API를 추가할 것을 제안합니다.

[편집자 주: 이 PEP에서 설명한 아이디어는 Python에 통합되었습니다. 이 PEP는 더 이상 구현을 정확하게 설명하지 않습니다.]

서론

전통적으로 Python의 타입은 PyTypeObject 타입의 전역 변수를 선언하고 정적 초기화자로 초기화하여 정적으로 생성되었습니다. 타입 객체의 슬롯은 Python 인터프리터와 관련된 Python 타입의 모든 측면을 설명합니다. 일부 슬롯에는 차원 정보(인스턴스의 기본 할당 크기 등)가 들어 있고, 다른 슬롯에는 다양한 플래그가 들어 있지만, 대부분의 슬롯은 여러 종류의 동작을 구현하는 함수에 대한 포인터입니다. NULL 포인터는 해당 타입이 특정 동작을 구현하지 않는다는 의미입니다. 이 경우 시스템은 기본 동작을 제공하거나, 해당 타입의 인스턴스에 대해 그 동작이 호출될 때 예외를 발생시킬 수 있습니다. 일반적으로 함께 정의되는 일부 함수 포인터 모음은 더 많은 함수 포인터를 포함하는 추가 구조체에 대한 포인터를 통해 간접적으로 얻습니다.

PyTypeObject 구조체를 초기화하는 세부 사항은 그러한 형태로 문서화되지는 않았지만 소스 코드의 예제에서 쉽게 파악할 수 있으며, 독자가 C에서 새로운 Python 타입을 생성하는 전통적인 방식에 충분히 익숙하다고 가정합니다.

이 PEP는 다음 기능을 도입합니다.

• 타입이 해당 인스턴스를 위한 팩토리 함수가 될 수 있습니다.
• C에서 타입의 서브타입을 만들 수 있습니다.
• class 문을 사용하여 Python에서 타입의 서브타입을 만들 수 있습니다.
• 타입으로부터의 다중 상속이 가능한 범위에서 지원됩니다. 다만 list와 딕셔너리로부터 다중 상속을 받을 수는 없습니다.
• 표준 강제 변환 함수(int, tuple, str 등)는 해당 타입 객체로 재정의되며, 이 타입 객체는 자체 팩토리 함수 역할을 합니다.
• class 문에는 새 클래스를 생성하는 데 사용할 메타클래스를 지정하는 __metaclass__ 선언을 포함할 수 있습니다.
• class 문에는 지원되는 인스턴스 변수의 구체적인 이름을 지정하는 __slots__ 선언을 포함할 수 있습니다.

이 PEP는 타입에 표준 내성을 추가하는 PEP 252를 기반으로 합니다. 예를 들어 특정 타입 객체가 tp_hash 슬롯을 초기화하면, 해당 타입 객체를 내성 검사할 때 __hash__ 메서드를 갖습니다. PEP 252는 모든 메서드를 포함하는 딕셔너리도 타입 객체에 추가합니다. Python 수준에서 이 딕셔너리는 내장 타입에 대해 읽기 전용이며, C 수준에서는 직접 액세스할 수 있습니다. 단, 초기화 과정의 일부인 경우를 제외하고 수정해서는 안 됩니다.

이진 호환성을 위해 tp_flags 슬롯의 플래그 비트는 아래에서 타입 객체에 도입되는 여러 새로운 슬롯의 존재를 나타냅니다. Py_TPFLAGS_HAVE_CLASS비트가 해당 tp_flags 슬롯에 설정되지 않은 타입은 모든 서브타이핑 슬롯에 NULL 값이 있는 것으로 간주합니다. (경고: 현재 구현 프로토타입은 이 플래그 비트를 검사하는 방식이 아직 일관되지 않습니다. 최종 릴리스 전에 이를 수정해야 합니다.)

현재 Python에서는 타입과 클래스가 구분됩니다. 이 PEP는 PEP 254와 함께 이러한 구분을 없앱니다. 그러나 하위 호환성을 위해 이 구분은 앞으로 수년간 남아 있을 가능성이 높으며, PEP 254가 없다면 그 차이는 여전히 큽니다. 타입은 궁극적으로 내장 타입을 베이스 클래스로 가지지만, 클래스는 궁극적으로 사용자 정의 클래스에서 파생됩니다. 따라서 이 PEP의 나머지 부분에서는 가능한 한 타입이라는 단어를 사용합니다. 여기에는 베이스 타입 또는 상위 타입, 파생 타입 또는 서브타입, 메타타입이 포함됩니다. 그러나 경우에 따라 용어가 불가피하게 혼용됩니다. 예를 들어 객체의 타입은 해당 객체의 __class__ 속성으로 지정되며, Python에서 서브타이핑은 class 문으로 표현됩니다. 추가적인 구분이 필요한 경우 사용자 정의 클래스를 “클래식” 클래스라고 부를 수 있습니다.

메타타입에 관하여

필연적으로 논의는 메타타입(또는 메타클래스)에 이릅니다. 메타타입은 Python에서 전혀 새로운 것이 아닙니다. Python은 항상 타입의 타입에 대해 말할 수 있었습니다.:

>>> a = 0
>>> type(a)
<type 'int'>
>>> type(type(a))
<type 'type'>
>>> type(type(type(a)))
<type 'type'>
>>>

이 예제에서 type(a)는 “일반” 타입이고, type(type(a))는 메타타입입니다. 배포된 상태에서는 모든 타입이 동일한 메타타입(PyType_Type이며, 이 자체도 자신의 메타타입입니다)을 가지지만, 이것이 필수 조건은 아닙니다. 실제로 유용하고 관련성 있는 서드파티 확장 기능인 Jim Fulton의 ExtensionClasses는 추가 메타타입을 생성합니다. types.ClassType로 알려진 클래식 클래스의 타입도 별개의 메타타입으로 간주할 수 있습니다.

메타타입과 밀접하게 연결된 기능은 “Don Beaudry hook”입니다. 이 기능은 메타타입이 호출 가능 객체라면 그 인스턴스(일반 타입인 객체)를 Python 클래스 문을 사용하여 서브클래스로 만들 수 있다(실제로는 서브타이핑할 수 있다)고 말합니다. 저는 내장 타입의 서브타이핑을 지원하기 위해 이 규칙을 사용할 것이며, 실제로 클래스 생성을 항상 단순히 메타타입을 호출하는 방식으로 처리하면 로직이 크게 단순해집니다. 베이스 클래스가 지정되지 않으면 기본 메타타입이 호출됩니다. 기본 메타타입은 “ClassType” 객체이므로, 일반적인 경우 클래스 문은 이전과 동일하게 동작합니다. (전역 변수 __metaclass__를 설정하여 모듈별로 이 기본값을 변경할 수 있습니다.)

Python은 Smalltalk와는 다른 방식으로 메타타입 또는 메타클래스 개념을 사용합니다. Smalltalk-80에는 일반 클래스의 계층 구조를 그대로 반영하는 메타클래스 계층 구조가 있으며, 메타클래스는 클래스에 1대1로 대응합니다(계층 구조의 루트에서 발생하는 몇 가지 특이한 경우는 제외합니다). 또한 각 클래스 문은 일반 클래스와 그 메타클래스를 모두 생성하여, 클래스 메서드는 메타클래스에 넣고 인스턴스 메서드는 일반 클래스에 넣습니다.

Smalltalk의 맥락에서는 이것이 훌륭할 수 있지만, Python에서 메타타입을 전통적으로 사용하는 방식과는 호환되지 않으며, 저는 Python 방식으로 계속 진행하는 것을 선호합니다. 이는 Python의 메타타입이 일반적으로 C로 작성되며 여러 일반 타입 사이에서 공유될 수 있음을 의미합니다. (Python에서 메타타입을 서브타이핑할 수 있게 되므로 메타타입을 사용하기 위해 반드시 C를 작성할 필요는 없게 되지만, Python 메타타입의 기능은 제한됩니다. 예를 들어 Python 코드가 원시 메모리를 할당하고 원하는 대로 초기화하는 것은 결코 허용되지 않습니다.)

메타타입은 타입에 대한 다양한 정책을 결정합니다. 예를 들어 타입이 호출될 때 발생하는 일, 타입이 얼마나 동적인지(생성된 후 타입의 __dict__를 수정할 수 있는지 여부), 메서드 결정 순서, 인스턴스 속성을 조회하는 방식 등을 결정합니다.

다중 상속을 최대한 활용하려는 경우에는 왼쪽에서 오른쪽으로 진행하는 깊이 우선 방식이 최선의 해결책이 아니라고 주장하겠습니다.

다중 상속에서는 서브타입의 메타타입이 모든 베이스 타입 메타타입의 자손이어야 한다고 주장하겠습니다.

메타타입에 대해서는 나중에 다시 다루겠습니다.

타입을 인스턴스의 팩토리로 만들기

전통적으로 각 타입에는 해당 타입의 인스턴스를 생성하는 C 팩토리 함수가 하나 이상 있습니다(PyTuple_New(), PyInt_FromLong() 등). 이러한 팩토리 함수는 객체를 위한 메모리를 할당하고 해당 메모리를 초기화하는 일을 모두 처리합니다. Python 2.0부터는 타입이 가비지 컬렉션에 참여하기로 선택한 경우 가비지 컬렉션 하위 시스템과도 연동해야 합니다(가비지 컬렉션 참여는 선택 사항이지만, 다른 객체에 대한 참조를 포함할 수 있어 참조 순환에 참여할 수 있는 이른바 “컨테이너” 타입에는 강력히 권장됩니다).

이 제안에서는 타입 객체가 해당 인스턴스의 팩토리 함수가 될 수 있어, 타입이 Python에서 직접 호출 가능 객체가 됩니다. 이는 클래스를 인스턴스화하는 방식을 모방합니다. 다양한 내장 타입의 인스턴스를 생성하기 위한 C API는 유효하게 유지되며, 일부 경우에는 더 효율적일 수 있습니다. 모든 타입이 자신의 팩토리 함수가 되는 것은 아닙니다.

타입 객체에는 새로운 슬롯인 tp_new가 있으며, 이 슬롯은 해당 타입의 인스턴스를 위한 팩토리로 동작할 수 있습니다. 이제 타입은 호출 가능 객체입니다. 메타타입인 PyType_Type에서 tp_call 슬롯이 설정되기 때문이며, 이 함수는 호출되는 타입의 tp_new 슬롯을 찾습니다.

설명: 일반 타입 객체(예: PyInt_Type 또는 PyList_Type)의 tp_call 슬롯은 해당 타입의 인스턴스가 호출될 때 어떤 일이 발생하는지 정의합니다. 특히 함수 타입인 PyFunction_Type의 tp_call 슬롯은 함수를 호출 가능 객체로 만드는 핵심입니다. 또 다른 예로, 정수는 호출 가능 객체가 아니므로 PyInt_Type.tp_call은 NULL입니다. 새로운 패러다임에서는 타입 객체를 호출 가능 객체로 만듭니다. 타입 객체는 자신의 메타클래스(PyType_Type)의 인스턴스이므로, 메타클래스의 tp_call 슬롯(PyType_Type.tp_call)은 어떤 타입 객체가 호출될 때 호출되는 함수를 가리킵니다. 이제 각 타입은 자신의 인스턴스를 생성하기 위해 서로 다른 작업을 수행해야 하므로, PyType_Type.tp_call은 호출되는 타입의 tp_new 슬롯으로 즉시 처리를 위임합니다. PyType_Type 자체도 호출 가능 객체입니다. 해당 타입의 tp_new 슬롯이 새 타입을 생성합니다. 이는 클래스 문이 사용합니다(위에서 설명한 Don Beaudry 훅을 공식화합니다). 그렇다면 PyType_Type을 호출 가능 객체로 만드는 것은 무엇입니까? 그것의 메타클래스의 tp_call 슬롯입니다. 그러나 그것은 자신의 메타클래스이므로, 결국 자신의 tp_call 슬롯입니다!

타입의 tp_new 슬롯이 NULL이면 예외가 발생합니다. 그렇지 않으면 tp_new 슬롯이 호출됩니다. tp_new 슬롯의 시그니처는 다음과 같습니다.

PyObject *tp_new(PyTypeObject *type,
                 PyObject *args,
                 PyObject *kwds)

여기서 ‘type’은 tp_new 슬롯이 호출되는 타입이며, ‘args’와 ‘kwds’는 호출에 전달되는 위치 인자와 키워드 인자로, tp_call에서 변경 없이 전달됩니다. (‘type’ 인자는 상속과 함께 사용됩니다. 자세한 내용은 아래를 참조하십시오.)

반환되는 객체 타입에는 제약이 없지만, 관례상 주어진 타입의 인스턴스여야 합니다. 새 객체를 반환할 필요는 없으며, 기존 객체에 대한 참조를 반환해도 됩니다. 반환 값은 항상 호출자가 소유하는 새로운 참조여야 합니다.

tp_new 슬롯이 객체를 반환하면, 결과 객체 타입의 tp_init() 슬롯이 NULL이 아닌 경우 이를 호출하여 추가 초기화를 시도합니다. 이 슬롯의 시그니처는 다음과 같습니다.:

int tp_init(PyObject *self,
            PyObject *args,
            PyObject *kwds)

이는 고전 클래스의 __init__() 메서드에 더 가깝게 대응하며, 실제로 슬롯/특수 메서드 대응 규칙에 따라 해당 메서드로 매핑됩니다. tp_new() 슬롯과 tp_init() 슬롯의 책임 차이는 이들이 보장하는 불변식에 있습니다. tp_new() 슬롯은 가장 필수적인 불변식만 보장해야 하며, 이러한 불변식이 없으면 객체를 구현하는 C 코드가 중단됩니다. tp_init() 슬롯은 재정의 가능한 사용자별 초기화에 사용해야 합니다. 딕셔너리 타입을 예로 들어 보겠습니다. 구현에는 절대 NULL이어서는 안 되는 해시 테이블에 대한 내부 포인터가 있습니다. 딕셔너리의 tp_new() 슬롯이 이 불변식을 처리합니다. 반면 딕셔너리의 tp_init() 슬롯은 전달된 인자를 바탕으로 딕셔너리에 초기 키와 값 집합을 제공하는 데 사용할 수 있습니다.

불변 객체 타입에서는 tp_init() 슬롯으로 초기화를 수행할 수 없다는 점에 유의하십시오. 이렇게 하면 Python 사용자가 초기화를 변경할 방법이 제공되기 때문입니다. 따라서 불변 객체는 일반적으로 빈 tp_init() 구현을 가지며, 모든 초기화를 tp_new() 슬롯에서 수행합니다.

tp_new() 슬롯이 tp_init() 슬롯을 직접 호출해서는 안 되는 이유가 궁금할 수 있습니다. 그 이유는 특정 상황(예: 영속 객체 지원)에서는 객체를 필요 이상으로 추가 초기화하지 않고 특정 타입의 객체를 생성할 수 있어야 하기 때문입니다. 이는 tp_init()을 호출하지 않고 tp_new() 슬롯을 호출하여 편리하게 수행할 수 있습니다. 또한 tp_init()이 호출되지 않거나 두 번 이상 호출될 수도 있으므로, 그 동작은 이러한 비정상적인 경우에도 견고해야 합니다.

일부 객체의 경우 tp_new()은 기존 객체를 반환할 수 있습니다. 예를 들어, 정수의 팩토리 함수는 -1부터 99까지의 정수를 캐시합니다. 이는 tp_new()의 타입 인자가 tp_new() 함수를 정의한 타입일 때(이 예에서는 type == &PyInt_Type인 경우) 그리고 이 타입의 tp_init() 슬롯이 아무 작업도 수행하지 않을 때만 허용됩니다. 타입 인자가 다른 경우, 객체를 생성하고 객체의 베이스 타입 부분을 초기화하기 위해 파생 타입의 tp_new()가 tp_new() 호출을 시작합니다. 이 경우 tp_new()는 항상 새 객체를 반환하거나 예외를 발생시켜야 합니다.

tp_new()와 tp_init()는 정확히 동일한 ‘args’ 및 ‘kwds’ 인자를 받아야 하며, 독립적으로 호출될 수 있으므로 두 함수 모두 인자가 허용 가능한지 확인해야 합니다.

객체 생성과 관련된 세 번째 슬롯이 있습니다. tp_alloc()입니다. 이 슬롯은 객체에 필요한 메모리를 할당하고, 참조 카운트(ob_refcnt)와 타입 포인터(ob_type)를 초기화하며, 객체의 나머지 부분을 모두 0으로 초기화하는 역할을 합니다. 또한 타입이 가비지 컬렉션을 지원하는 경우 객체를 가비지 컬렉션 서브시스템에 등록해야 합니다. 이 슬롯은 파생 타입이 초기화 코드와 별도로 메모리 할당 정책(예: 사용할 힙)을 재정의할 수 있도록 존재합니다. 시그니처는 다음과 같습니다.:

PyObject *tp_alloc(PyTypeObject *type, int nitems)

타입 인자는 새 객체의 타입입니다. nitems 인자는 일반적으로 0이지만, 가변 할당 크기를 갖는 객체(기본적으로 문자열, 튜플 및 long)의 경우에는 예외입니다. 할당 크기는 다음 표현식으로 지정됩니다.:

type->tp_basicsize  +  nitems * type->tp_itemsize

tp_alloc 슬롯은 서브클래스화할 수 있는 타입에만 사용됩니다. 베이스 클래스의 tp_new() 함수는 첫 번째 인자로 전달된 타입의 tp_alloc() 슬롯을 호출해야 합니다. 항목 수를 계산하는 것은 tp_new() 함수의 책임입니다. type->tp_itemsize 멤버가 0이 아니면 tp_alloc 슬롯은 새 객체의 ob_size 멤버를 설정합니다.

(참고: 특정 디버깅 컴파일 모드에서는 타입 구조체에 이미 tp_alloc이라는 이름의 멤버와 tp_free 슬롯, 그리고 할당 및 할당 해제 횟수를 나타내는 카운터가 있었습니다. 이들은 tp_allocs와 tp_deallocs로 이름이 변경되었습니다.)

tp_alloc() 및 tp_new()에 대한 표준 구현을 사용할 수 있습니다. PyType_GenericAlloc()은 표준 힙에서 객체를 할당하고 올바르게 초기화합니다. 이 함수는 위의 공식을 사용하여 할당할 메모리 양을 결정하고 GC 등록을 처리합니다. 이 구현을 사용하지 않을 유일한 이유는 다른 힙에서 객체를 할당하기 위해서입니다(정수나 튜플처럼 매우 작고 자주 사용되는 일부 객체가 이에 해당합니다). PyType_GenericNew()는 거의 아무것도 추가하지 않으며, 단지 nitems에 0을 지정하여 해당 타입의 tp_alloc() 슬롯을 호출합니다. 그러나 모든 초기화를 tp_init() 슬롯에서 수행하는 변경 가능한 타입의 경우에는 이것이 바로 적합한 방법일 수 있습니다.

서브타이핑을 위한 타입 준비

서브타이핑의 기본 개념은 C++의 단일 상속과 매우 유사합니다. 베이스 타입은 구조체 선언(C++ 클래스 선언과 유사함)과 타입 객체(C++ vtable과 유사함)로 설명됩니다. 파생 타입은 구조체를 확장할 수 있지만(베이스 구조체 멤버의 이름, 순서 및 타입은 변경하지 않아야 함), 타입 객체의 특정 슬롯을 재정의하고 나머지 슬롯은 동일하게 유지할 수 있습니다. (C++ vtable과 달리 모든 Python 타입 객체는 동일한 메모리 레이아웃을 가집니다.)

베이스 타입은 다음을 수행해야 합니다.

• tp_flags에 플래그 값 Py_TPFLAGS_BASETYPE을 추가해야 합니다.
• tp_new(), tp_alloc() 및 선택적 tp_init() 슬롯을 선언하고 사용해야 합니다.
• tp_dealloc() 및 tp_free()를 선언하고 사용해야 합니다.
• 객체 구조체 선언을 내보내야 합니다.
• 서브타이핑을 인식하는 타입 검사 매크로를 내보내십시오.

tp_new(), tp_alloc() 및 tp_init()의 요구 사항과 시그니처는 앞에서 이미 논의했습니다. tp_alloc()은 메모리를 할당하고 대부분 0으로 초기화해야 하며, tp_new()는 tp_alloc() 슬롯을 호출한 다음 최소한으로 필요한 초기화를 진행해야 합니다. tp_init()은 변경 가능한 객체를 보다 광범위하게 초기화할 때 사용해야 합니다.

객체의 수명이 끝날 때에도 이와 유사한 규칙이 있다는 것은 놀랍지 않습니다. 관련 슬롯은 지금까지 Python 확장 타입을 구현한 사람이라면 누구나 익숙한 tp_dealloc()과 새로 등장한 tp_free()입니다. (이름이 완전히 대칭적이지는 않습니다. tp_free()가 tp_alloc()에 대응하는 것은 괜찮지만, tp_dealloc()은 tp_new()에 대응합니다. tp_dealloc 슬롯의 이름을 바꾸어야 할지도 모릅니다?)

tp_free() 슬롯은 메모리를 해제하고 객체를 가비지 컬렉션 하위 시스템에서 등록 해제하는 데 사용해야 하며, 파생 클래스에서 재정의할 수 있습니다. tp_dealloc()은 객체를 초기화 해제한 다음(일반적으로 다양한 하위 객체에 Py_XDECREF()를 호출하여 수행합니다) tp_free()를 호출해 메모리를 할당 해제해야 합니다. tp_dealloc()의 시그니처는 예전부터 늘 동일했습니다.:

void tp_dealloc(PyObject *object)

tp_free()의 시그니처도 동일합니다.:

void tp_free(PyObject *object)

(이 PEP의 이전 버전에서는 tp_clear() 슬롯에 별도의 역할을 부여하기도 했습니다. 이는 좋지 않은 생각으로 판명되었습니다.)

C에서 유용하게 서브타이핑하려면, 타입은 서브타입을 파생하는 데 필요하므로 헤더 파일을 통해 해당 인스턴스의 구조 선언을 내보내야 합니다. 베이스 타입의 타입 객체도 내보내야 합니다.

베이스 타입에 타입 검사 매크로(예: PyDict_Check())가 있다면, 이 매크로가 서브타입을 인식하도록 만들어야 합니다. 이는 새로운 PyObject_TypeCheck(object, type) 매크로를 사용하여 수행할 수 있으며, 이 매크로는 베이스 클래스 링크를 따라가는 함수를 호출합니다.

PyObject_TypeCheck() 매크로에는 약간의 최적화가 포함되어 있습니다. 먼저 object->ob_type을 타입 인자와 직접 비교하고, 일치하면 함수 호출을 우회합니다. 이렇게 하면 대부분의 상황에서 충분히 빠르게 동작합니다.

타입 검사 매크로의 이러한 변경으로 인해 베이스 타입의 인스턴스를 요구하는 C 함수가 파생 타입의 인스턴스로 호출될 수 있다는 점에 유의하십시오. 특정 타입의 서브타이핑을 활성화하기 전에, 문제가 발생하지 않도록 해당 타입의 코드를 점검해야 합니다. 프로토타입에서는 내장 Python 객체 타입에 대해 정확한 타입 일치도 검사하는 또 다른 타입 검사 매크로를 추가하는 것이 유용한 것으로 입증되었습니다. (예를 들어, PyDict_Check(x)는 x가 딕셔너리의 인스턴스이거나 딕셔너리 서브클래스의 인스턴스이면 참인 반면, PyDict_CheckExact(x)는 x가 딕셔너리인 경우에만 참입니다.)

C에서 내장 타입의 서브타입 만들기

가장 단순한 형태의 서브타이핑은 C에서의 서브타이핑입니다. 이는 C 코드가 일부 문제를 인식하도록 요구할 수 있고, 규칙을 따르지 않는 C 코드가 코어 덤프를 일으키는 것도 허용할 수 있기 때문에 가장 단순한 형태입니다. 더욱 단순하게 하기 위해 단일 상속으로 제한됩니다.

tp_itemsize가 0인 변경 가능한 베이스 타입에서 파생한다고 가정하겠습니다. 서브타입 코드는 GC를 인식하지 않지만, 베이스 타입에서 GC 인식을 상속할 수 있습니다(이는 자동으로 이루어집니다). 베이스 타입은 표준 힙을 사용하여 할당됩니다.

파생 타입은 베이스 타입의 구조를 포함하는 타입 구조를 선언하는 것으로 시작합니다. 예를 들어 다음은 내장 리스트 타입의 서브타입에 대한 타입 구조입니다.:

typedef struct {
    PyListObject list;
    int state;
} spamlistobject;

베이스 타입 구조 멤버(여기서는 PyListObject)는 구조의 첫 번째 멤버여야 하며, 그 뒤에 오는 멤버는 추가 항목이라는 점에 유의하십시오. 또한 베이스 타입이 포인터를 통해 참조되지 않는다는 점에도 유의하십시오. 베이스 타입 구조의 실제 내용을 포함해야 합니다! (목표는 서브타입 인스턴스의 시작 부분 메모리 배치가 베이스 타입 인스턴스의 메모리 배치와 동일하도록 하는 것입니다.)

다음으로, 파생 형식은 타입 객체를 선언하고 초기화해야 합니다. 타입 객체의 대부분 슬롯은 0으로 초기화할 수 있으며, 이는 베이스 형식의 슬롯을 해당 슬롯에 복사해야 함을 나타냅니다. 다음과 같은 일부 슬롯은 올바르게 초기화해야 합니다.

• 객체 헤더는 평소와 같이 채워야 하며, 타입은 &PyType_Type이어야 합니다.
• tp_basicsize 슬롯은 서브타입 인스턴스 구조체의 크기로 설정해야 합니다(위의 예에서는 sizeof(spamlistobject)입니다).
• tp_base 슬롯은 기본 타입의 타입 객체 주소로 설정해야 합니다.
• 파생 슬롯이 포인터 멤버를 정의하는 경우 tp_dealloc 슬롯 함수에 특별한 주의가 필요합니다. 아래를 참조하십시오. 그렇지 않은 경우 베이스 형식의 할당 해제 함수를 상속하도록 0으로 설정할 수 있습니다.
• tp_flags 슬롯은 일반적인 Py_TPFLAGS_DEFAULT 값으로 설정해야 합니다.
• tp_name 슬롯은 설정해야 하며, tp_doc도 설정하는 것이 좋습니다(이들은 상속되지 않습니다).

하위 형식이 추가 구조체 멤버를 정의하지 않는 경우(새로운 데이터가 아닌 새로운 동작만 정의하는 경우), tp_basicsize 및 tp_dealloc 슬롯은 0으로 설정된 상태로 둘 수 있습니다.

하위 형식의 tp_dealloc 슬롯에는 특별한 주의가 필요합니다. 파생 형식이 객체 할당 해제 시 DECREF하거나 해제해야 하는 추가 포인터 멤버를 정의하지 않는 경우, 이를 0으로 설정할 수 있습니다. 그렇지 않으면 하위 형식의 tp_dealloc() 함수는 모든 PyObject * 멤버에 대해 Py_XDECREF()를 호출하고, 소유한 다른 포인터에 대해서는 올바른 메모리 해제 함수를 호출한 다음, 베이스 클래스의 tp_dealloc() 슬롯을 호출해야 합니다. 이 호출은 베이스 형식의 타입 구조체를 통해 수행해야 하며, 표준 리스트 형식에서 파생하는 경우를 예로 들 수 있습니다.:

PyList_Type.tp_dealloc(self);

하위 형식이 베이스 형식과 다른 할당 힙을 사용하려면 tp_alloc() 및 tp_free() 슬롯을 모두 재정의해야 합니다. 이들은 각각 베이스 클래스의 tp_new() 및 tp_dealloc() 슬롯에 의해 호출됩니다.

타입 초기화를 완료하려면 PyType_InitDict()를 호출해야 합니다. 이는 하위 형식에서 0으로 초기화된 슬롯을 해당 베이스 형식 슬롯의 값으로 대체합니다. (또한 타입의 딕셔너리인 tp_dict를 채우고, 타입 객체에 필요한 여러 다른 초기화도 수행합니다.)

하위 형식은 해당 형식에 대해 PyType_InitDict()를 호출하기 전까지 사용할 수 없습니다. 하위 형식이 모듈에 속한다고 가정하면 모듈 초기화 중에 이를 수행하는 것이 가장 좋습니다. 특정 모듈에 속하지 않는 Python 코어에 추가된 하위 형식의 경우, 생성자 함수에서 하위 형식을 초기화하는 방법도 있습니다. PyType_InitDict()를 두 번 이상 호출해도 됩니다. 두 번째 호출과 그 이후의 호출은 아무런 효과가 없습니다. 불필요한 호출을 피하려면 tp_dict==NULL에 대한 검사를 수행할 수 있습니다.

(Python 인터프리터 초기화 중에는 일부 타입이 실제로 초기화되기 전에 사용됩니다. 실제로 필요한 슬롯, 특히 tp_dealloc이 초기화되어 있으면 이는 작동하지만, 취약한 방식이므로 일반적인 관행으로 권장하지 않습니다.)

하위 형식 인스턴스를 생성하려면 하위 형식의 tp_new() 슬롯을 호출합니다. 이 함수는 먼저 베이스 형식의 tp_new() 슬롯을 호출한 다음 하위 형식의 추가 데이터 멤버를 초기화해야 합니다. 인스턴스를 추가로 초기화하려면 일반적으로 tp_init() 슬롯을 호출합니다. tp_new() 슬롯은 tp_init() 슬롯을 호출해서는 안 된다는 점에 유의하십시오. 이는 tp_new()의 호출자(일반적으로 팩토리 함수)가 수행할 일입니다. tp_init()를 호출하지 않는 것이 적절한 경우도 있습니다.

하위 형식이 tp_init() 슬롯을 정의하는 경우, tp_init() 슬롯은 일반적으로 먼저 베이스 형식의 tp_init() 슬롯을 호출해야 합니다.

(XXX 여기에는 인자 전달에 관한 문단이 한두 개 있어야 합니다.)

Python에서의 하위 형식화

Python에서 선택된 내장 타입의 서브타이핑을 클래스 문을 통해 허용하는 것이 다음 단계입니다. 지금은 단일 상속으로 제한하면, 간단한 클래스 문에서는 다음과 같이 동작합니다.:

class C(B):
    var1 = 1
    def method1(self): pass
    # etc.

클래스 문의 본문은 새로운 환경(기본적으로 로컬 네임스페이스로 사용되는 새 딕셔너리)에서 실행된 다음 C가 생성됩니다. 다음에서는 C가 생성되는 방식을 설명합니다.

B가 타입 객체라고 가정합니다. 타입 객체는 객체이고 모든 객체에는 타입이 있으므로 B에도 타입이 있습니다. B 자체가 타입이므로 그 타입을 메타타입이라고도 부릅니다. B의 메타타입은 type(B) 또는 B.__class__를 통해 접근할 수 있습니다(후자의 표기법은 타입에 새로 도입된 것으로, PEP 252에서 소개되었습니다). 이 메타타입을 M(Metatype의 약자)이라고 하겠습니다. 클래스 문은 새로운 타입 C를 생성합니다. C는 B와 마찬가지로 타입 객체가 되므로, C의 생성을 메타타입 M의 인스턴스화로 간주합니다. 서브클래스를 생성하려면 다음 정보가 제공되어야 합니다:

• 이름(이 예에서는 문자열 “C”)입니다;
• 베이스( B를 포함하는 싱글턴 튜플)입니다;
• 클래스 본문을 실행한 결과를 딕셔너리 형식으로 나타낸 것입니다(예: {"var1": 1, "method1": <functionmethod1 at ...>, ...}).

클래스 문은 다음 호출을 수행합니다.:

C = M("C", (B,), dict)

여기서 dict는 클래스 본문을 실행한 결과인 딕셔너리입니다. 다시 말해 메타타입(M)이 호출됩니다.

이 예에는 베이스가 하나뿐이지만, 여전히 베이스의 (싱글턴) 시퀀스를 전달한다는 점에 유의하십시오. 이렇게 하면 다중 상속의 경우와 인터페이스가 동일해집니다.

현재 Python에서는 이를 발명자의 이름을 따서 “Don Beaudry hook”이라고 부릅니다. 이는 베이스 클래스가 일반 클래스가 아닐 때만 호출되는 예외적인 경우입니다. 일반 베이스 클래스의 경우(또는 베이스 클래스가 지정되지 않은 경우), 현재 Python은 클래스의 C 수준 팩토리 함수인 PyClass_New()를 직접 호출합니다.

새로운 시스템에서는 Python이 always 메타타입을 결정하고 위와 같이 호출하도록 변경됩니다. 하나 이상의 베이스가 지정되면 첫 번째 베이스의 타입이 메타타입으로 사용되고, 베이스가 지정되지 않으면 기본 메타타입이 선택됩니다. 기본 메타타입을 “classic” 클래스의 메타타입인 PyClass_Type으로 설정하면 클래스 문의 고전적 동작이 유지됩니다. 이 기본값은 전역 변수 __metaclass__를 설정하여 모듈별로 변경할 수 있습니다.

여기에는 두 가지 추가적인 개선 사항이 있습니다. 첫째, 메타타입을 직접 지정할 수 있다는 점이 유용합니다. 클래스 본문에서 __metaclass__라는 변수를 정의하면 그것이 호출할 메타타입이 됩니다. (모듈 수준에서 __metaclass__를 설정하는 것은 베이스 클래스와 명시적인 __metaclass__ 선언이 없는 클래스 문에만 영향을 줍니다. 그러나 클래스 본문에서 __metaclass__를 설정하면 기본 메타타입을 무조건 재정의합니다.)

둘째, 다중 베이스를 사용할 때 모든 베이스가 동일한 메타타입을 가질 필요는 없습니다. 이를 메타클래스 충돌이라고 합니다 [1]. 일부 메타클래스 충돌은 모든 다른 주어진 메타타입에서 파생되는 메타타입을 베이스 집합에서 검색하여 해결할 수 있습니다. 그러한 메타타입을 찾을 수 없으면 예외가 발생하고 클래스 문이 실패합니다.

이 충돌 해결은 메타타입 생성자를 통해 구현할 수 있습니다. 클래스 문은 첫 번째 베이스의 메타타입(또는 __metaclass__ 변수로 지정된 메타타입)을 호출할 뿐이며, 이 메타타입의 생성자는 가장 파생된 메타타입을 찾습니다. 그것이 자기 자신이면 계속 진행하고, 그렇지 않으면 해당 메타타입의 생성자를 호출합니다. (궁극적인 유연성을 위해 다른 메타타입이 모든 베이스가 동일한 메타타입을 가져야 한다거나, 베이스 클래스가 하나뿐이어야 한다거나, 그 밖의 조건을 요구하도록 선택할 수도 있습니다.)

([1]에서는 지정된 모든 메타클래스의 서브클래스인 새로운 메타클래스가 자동으로 파생됩니다. 그러나 Python에서 다양한 메타클래스의 충돌하는 메서드 정의를 어떻게 병합해야 하는지는 논란의 여지가 있으므로, 저는 이것이 실현 가능하다고 생각하지 않습니다. 필요하다면 사용자가 이러한 메타클래스를 수동으로 파생하고 __metaclass__ 변수로 지정할 수 있습니다. 이를 수행하는 새로운 메타클래스를 만드는 것도 가능합니다.)

M을 호출하려면 M 자체에도 타입, 즉 메타-메타타입이 있어야 한다는 점에 유의하십시오. 그리고 메타-메타타입에도 타입, 즉 메타-메타-메타타입이 있습니다. 이런 식으로 계속됩니다. 일반적으로 메타타입을 자신의 메타타입으로 만들어 어느 단계에서 이 연쇄를 중단합니다. 실제로 Python에서 그렇게 합니다. PyType_Type의 ob_type 참조는 &PyType_Type로 설정됩니다. 서드 파티 메타타입이 없는 경우 PyType_Type은 Python 인터프리터에서 유일한 메타타입입니다.

(이 PEP의 이전 버전에는 메타 수준이 하나 더 있었고, “turtle”이라는 메타-메타타입이 있었습니다. 이것은 불필요한 것으로 밝혀졌습니다.)

어쨌든 C를 생성하는 작업은 M의 tp_new() 슬롯이 수행합니다. 이 슬롯은 다음을 포함하는 “확장된” 타입 구조체를 위한 공간을 할당합니다. 타입 객체, 보조 구조체(as_sequence 등), 타입 이름을 포함하는 문자열 객체(타입 객체가 여전히 이 객체를 참조하는 동안 이 객체가 할당 해제되지 않도록 하기 위한 것), 그리고 일부 보조 저장 공간(이는 나중에 설명합니다)입니다. 이 슬롯은 몇몇 중요한 슬롯을 제외한 이 저장 공간을 0으로 초기화합니다(예를 들어 tp_name은 타입 이름을 가리키도록 설정합니다). 그런 다음 tp_base 슬롯을 B를 가리키도록 설정합니다. 그런 다음 PyType_InitDict()를 호출하여 B의 슬롯을 상속합니다. 마지막으로 C의 tp_dict 슬롯을 네임스페이스 딕셔너리의 내용으로 갱신합니다(M 호출의 세 번째 인자).

다중 상속

Python 클래스 문은 다중 상속을 지원하며, 내장 타입이 관여하는 다중 상속도 지원할 것입니다.

그러나 몇 가지 제한이 있습니다. C 런타임 아키텍처에서는 몇몇 특수한 경우를 제외하면 서로 다른 두 내장 타입의 의미 있는 서브타입을 만드는 것이 실현 가능하지 않습니다. 완전히 일반적인 다중 상속을 지원하도록 C 런타임을 변경하는 것은 코드 기반을 지나치게 크게 뒤흔드는 일이 될 것입니다.

서로 다른 내장 타입에서 다중 상속을 할 때의 주요 문제는 내장 타입의 C 구현이 구조체 멤버에 직접 접근한다는 사실에서 비롯됩니다. C 컴파일러는 객체 포인터를 기준으로 오프셋을 생성하며, 그것으로 끝입니다. 예를 들어 리스트 타입 구조체와 딕셔너리 타입 구조체는 각각 서로 다르지만 겹치는 구조체 멤버를 여러 개 선언합니다. 리스트를 예상하고 객체에 접근하는 C 함수에 딕셔너리를 전달하면 작동하지 않으며 그 반대도 마찬가지입니다. 리스트와 딕셔너리에 접근하는 모든 코드를 다시 작성하지 않고는 이를 해결할 방법도 거의 없습니다. 이는 너무 많은 작업이므로 그렇게 하지 않을 것입니다.

다중 상속의 문제는 충돌하는 구조체 멤버 할당 때문에 발생합니다. Python에서 정의된 클래스는 일반적으로 인스턴스 변수를 구조체 멤버에 저장하지 않습니다. 인스턴스 변수는 인스턴스 딕셔너리에 저장됩니다. 이것이 부분적인 해결책의 핵심입니다. 다음과 같은 두 클래스를 가정해 보십시오.:

class A(dictionary):
    def foo(self): pass

class B(dictionary):
    def bar(self): pass

class C(A, B): pass

(여기서 ‘dictionary’는 내장 딕셔너리 객체의 타입, 즉 type({}) 또는 {}.__class__ 또는 types.DictType입니다.) 구조 레이아웃을 살펴보면 A 인스턴스는 딕셔너리 다음에 __dict__ 포인터가 오는 레이아웃을 가지며, B 인스턴스도 같은 레이아웃을 가집니다. 구조 멤버 레이아웃 간 충돌이 없으므로 이는 문제가 없습니다.

다음은 또 다른 예입니다.:

class X(object):
    def foo(self): pass

class Y(dictionary):
    def bar(self): pass

class Z(X, Y): pass

(여기서 ‘object’는 모든 내장 타입의 기반이며, 그 구조 레이아웃에는 ob_refcnt 및 ob_type 멤버만 포함됩니다.) 이 예는 X 인스턴스의 __dict__ 포인터가 Y 인스턴스의 것과 다른 오프셋을 가지므로 더 복잡합니다. Z 인스턴스의 __dict__ 포인터는 어디에 있습니까? 답은 __dict__ 포인터의 오프셋이 하드코딩되어 있지 않고 타입 객체에 저장된다는 것입니다.

특정 머신에서 ‘object’ 구조체의 길이가 8바이트이고, ‘딕셔너리’ 구조체의 크기가 60바이트이며, 객체 포인터의 크기가 4바이트라고 가정합니다. 그러면 X 구조체는 12바이트이고(객체 구조체 다음에 __dict__ 포인터가 옵니다), Y 구조체는 64바이트입니다(딕셔너리 구조체 다음에 __dict__ 포인터가 옵니다). 이 예에서 Z 구조체는 Y 구조체와 동일한 레이아웃을 가집니다. 각 타입 객체(X, Y 및 Z)에는 __dict__ 포인터를 찾는 데 사용되는 “__dict__ offset”이 있습니다. 따라서 인스턴스 변수를 조회하는 절차는 다음과 같습니다.

1. 인스턴스의 타입을 가져오십시오.
2. 타입 객체에서 __dict__ 오프셋을 가져오십시오.
3. 인스턴스 포인터에 __dict__ 오프셋을 더하십시오.
4. 그 결과로 얻은 주소에서 딕셔너리 참조를 찾으십시오.
5. 해당 딕셔너리에서 인스턴스 변수 이름을 조회하십시오.

물론 이 절차는 C로만 구현할 수 있으며, 일부 세부 사항은 생략했습니다. 그러나 이를 통해 클래식 클래스에서 사용할 수 있는 것과 유사한 다중 상속 패턴을 사용할 수 있습니다.

XXX 기반 클래스 호환성을 결정하는 완전한 알고리즘을 여기에 작성해야 하지만, 지금은 그럴 엄두가 나지 않습니다. 아래에 언급된 구현의 typeobject.c에 있는 best_base()를 살펴보십시오.

MRO: 메서드 결정 순서 (조회 규칙)

다중 상속을 사용하면 메서드 결정 순서에 관한 문제가 생깁니다. 즉, 주어진 이름의 메서드를 찾기 위해 클래스나 타입 및 그 기반 클래스들을 검색하는 순서입니다.

클래식 Python에서는 다음 재귀 함수로 규칙을 정의하며, 이를 왼쪽에서 오른쪽으로 깊이 우선 탐색하는 규칙이라고도 합니다.:

def classic_lookup(cls, name):
    if cls.__dict__.has_key(name):
        return cls.__dict__[name]
    for base in cls.__bases__:
        try:
            return classic_lookup(base, name)
        except AttributeError:
            pass
    raise AttributeError, name

이 규칙의 문제점은 “다이아몬드 다이어그램”을 고려하면 분명해집니다.:

      class A:
        ^ ^  def save(self): ...
       /   \
      /     \
     /       \
    /         \
class B     class C:
    ^         ^  def save(self): ...
     \       /
      \     /
       \   /
        \ /
      class D

화살표는 서브타입에서 기반 타입인 type(s)를 가리킵니다. 이 특정 다이어그램은 B와 C가 A에서 파생되고, D가 B와 C에서 파생된다는 뜻입니다(따라서 간접적으로 A에서도 파생됩니다).

기반 클래스 A에 정의된 메서드 save()를 C가 재정의한다고 가정하십시오. (C.save()는 아마 A.save()를 호출한 다음 자체 상태의 일부를 저장할 것입니다.) B와 D는 save()를 재정의하지 않습니다. D 인스턴스에서 save()를 호출하면 어떤 메서드가 호출됩니까? 클래식 조회 규칙에 따르면 A.save()가 호출되고 C.save()는 무시됩니다!

이는 좋지 않습니다. 아마도 C가 망가질 것입니다(C의 상태가 저장되지 않음). 이는 애초에 C를 상속하는 전체 목적을 무너뜨립니다.

왜 이것은 기존 Python에서는 문제가 되지 않았습니까? 다이아몬드 도식은 기존 Python 클래스 계층에서는 거의 나타나지 않습니다. 대부분의 클래스 계층은 단일 상속을 사용하며, 다중 상속은 대개 믹스인 클래스로 제한됩니다. 사실 여기에서 보이는 문제가 기존 Python에서 다중 상속이 인기가 없는 이유일 가능성이 높습니다.

왜 이것이 새 시스템에서는 문제가 됩니까? 타입 계층의 최상위에 있는 ‘object’ 타입은 서브타입에서 유용하게 확장할 수 있는 여러 메서드를 정의하며, 예를 들어 __getattr__()가 있습니다.

(참고로, 기존 Python에서 __getattr__() 메서드는 실제로 속성 가져오기 연산의 구현이 아니라, 일반적인 방법으로 속성을 찾을 수 없을 때만 호출되는 훅입니다. 이것은 단점으로 자주 지적되어 왔습니다 – 일부 클래스 설계에는 모든 속성 참조에 대해 호출되는 __getattr__() 메서드가 필요할 타당한 이유가 있습니다. 그러나 물론 그러려면 이 메서드가 기본 구현을 직접 호출할 수 있어야 합니다. 가장 자연스러운 방법은 기본 구현을 object.__getattr__(self, name)으로 사용할 수 있게 만드는 것입니다.)

따라서 다음과 같은 기존 클래스 계층은:

class B     class C:
    ^         ^  def __getattr__(self, name): ...
     \       /
      \     /
       \   /
        \ /
      class D

새 시스템에서는 다이아몬드 도식으로 바뀌며:

      object:
        ^ ^  __getattr__()
       /   \
      /     \
     /       \
    /         \
class B     class C:
    ^         ^  def __getattr__(self, name): ...
     \       /
      \     /
       \   /
        \ /
      class D

원래 도식에서는 C.__getattr__()이 호출되지만, 새 시스템에서 기존 조회 규칙을 사용하면 object.__getattr__()이 호출됩니다!

다행히 더 나은 조회 규칙이 있습니다. 설명하기는 조금 어렵지만, 다이아몬드 도식에서 올바르게 작동하며, 상속 그래프에 다이아몬드가 없을 때(즉 트리일 때)에는 기존 조회 규칙과 동일합니다.

새 조회 규칙은 상속 도식의 모든 클래스를 검색될 순서대로 나열한 목록을 구성합니다. 이 목록은 시간을 절약하기 위해 클래스 정의 시점에 구성됩니다. 새 조회 규칙을 설명하기 위해, 먼저 기존 조회 규칙에서 그러한 목록이 어떤 모습일지 살펴보겠습니다. 다이아몬드가 있으면 기존 조회가 일부 클래스를 여러 번 방문한다는 점에 유의하십시오. 예를 들어, 위의 ABCD 다이아몬드 도식에서 기존 조회 규칙은 다음 순서로 클래스들을 방문합니다.:

D, B, A, C, A

목록에서 A가 두 번 나타나는 것을 확인하십시오. 두 번째 항목은 중복입니다. 첫 번째 항목을 검색할 때 이미 그곳에서 찾을 수 있는 모든 것을 찾았을 것이기 때문입니다.

이 점을 이용해 새 조회 규칙을 설명하겠습니다. 기존 조회 규칙을 사용하여 검색될 클래스 목록을 중복 항목을 포함해 구성하십시오. 이제 목록에 여러 번 나타나는 각 클래스에 대해 마지막 항목만 남기고 나머지 모든 항목을 제거하십시오. 이렇게 만들어진 목록에는 각 조상 클래스가 정확히 한 번씩 포함됩니다(예제의 가장 많이 파생된 클래스인 D도 포함됩니다).

이 순서로 메서드를 검색하면 다이아몬드 도식에서 올바르게 작동합니다. 목록을 구성하는 방식 때문에 다이아몬드가 관련되지 않은 상황에서는 검색 순서가 바뀌지 않습니다.

이것은 하위 호환성이 깨지는 것이 아닙니까? 기존 코드가 손상되지 않겠습니까? 모든 클래스의 메서드 결정 순서를 변경한다면 그렇게 됩니다. 그러나 Python 2.2에서는 새로운 조회 규칙이 새로운 기능인 내장 타입에서 파생된 타입에만 적용됩니다. 베이스 클래스가 없는 클래스 문은 “클래식 클래스”를 생성하며, 베이스 클래스 자체가 클래식 클래스인 클래스 문도 마찬가지입니다. 클래식 클래스에는 클래식 조회 규칙을 사용합니다. (클래식 클래스에 새로운 조회 규칙을 시험하려면 다른 메타클래스를 명시적으로 지정할 수 있습니다.) 또한 메서드 결정 순서의 변경으로 영향을 받을 메서드를 찾도록 클래스 계층 구조를 분석하는 도구도 제공합니다.

XXX Damian Conway가 제시한 새로운 MRO의 동기를 설명하는 또 다른 방식은 다음과 같습니다. (이전 검색 순서를 사용할 때) 아직 탐색하지 않은 파생 클래스에 해당 메서드가 정의되어 있다면 베이스 클래스에 정의된 메서드를 절대로 사용하지 않습니다.

XXX 수행할 작업

이 PEP에서 논의할 추가 주제:

• 하위 호환성 문제!!!
• 클래스 메서드와 정적 메서드
• 협력 메서드와 super()
• 타입 객체 슬롯(tp_foo)과 특수 메서드(__foo__) 간의 매핑(실제로는 PEP 252에 속할 수도 있습니다)
• 내장 타입(object, int, str, list 등)의 내장 이름
• __dict__ 및 __dictoffset__
• __slots__
• HEAPTYPE 플래그 비트
• GC 지원
• 새로운 모든 함수에 대한 API 문서
• __new__ 사용 방법
• 메타클래스 작성(mro() 등 사용)
• 고수준 사용자 개요

미해결 문제

• __del__이 필요합니까?
• __dict__ 및 __bases__에 대한 할당
• 일관되지 않은 이름 지정 (예: tp_dealloc/tp_new/tp_init/tp_alloc/tp_free)
• 내장 별칭 ‘dict’를 ‘딕셔너리’에 추가합니까?
• dict/list 등의 서브클래스를 시스템 함수에 전달할 때 __getitem__ 재정의 등이 항상 사용되는 것은 아닙니다.

구현

이 PEP(및 PEP 252)의 프로토타입 구현은 CVS와 Python 2.2 알파 및 베타 릴리스 시리즈에서 사용할 수 있습니다. 여기에 설명된 기능의 몇 가지 예제는 Lib/test/test_descr.py 파일과 확장 모듈 Modules/xxsubtype.c를 참조하십시오.

참고 문헌

[1] (1, 2)

Ira R. Forman과 Scott H. Danforth 지음, “Putting Metaclasses to Work”, Addison-Wesley 1999. (http://www.aw.com/product/0,2627,0201433052,00.html)

Copyright

This document has been placed in the public domain.