3. 데이터 모델¶

3.1. 객체, 값, 형¶

객체 (Objects)는 파이썬이 데이터(data)를 추상화한 것(abstraction)입니다. 파이썬 프로그램의 모든 데이터는 객체나 객체 간의 관계로 표현됩니다. (폰 노이만(Von Neumann)의 "프로그램 내장식 컴퓨터(stored program computer)" 모델을 따르고, 또 그 관점에서 코드 역시 객체로 표현됩니다.)

flowdas

폰 노이만 구조 이후의 하버드 구조와 대비시켜 볼 수도 있겠습니다. 폰 노이만 구조가 데이터와 코드를 같은 공간에 내장하는 반면, 하버드 구조에서는 데이터와 코드를 별도의 공간에 내장합니다. 이 것이 오히려 현대의 컴퓨터에 더 가깝다고 볼 수 있습니다. 파이썬은 코드 조차도 그 형태가 분명한 객체로 다루기 때문에, 노이만 구조에 가까운 가상 머신을 제공한다고 본다는 뜻으로 해석할 수 있습니다.

모든 객체는 아이덴티티(identity), 형(type), 값(value)을 갖습니다. 객체의 아이덴티티 는 한 번 만들어진 후에는 변경되지 않습니다. 메모리상에서의 객체의 주소로 생각해도 좋습니다. 'is' 연산자는 두 객체의 아이덴티티를 비교합니다; id() 함수는 아이덴티티를 정수로 표현한 값을 돌려줍니다.

CPython implementation detail: CPython 의 경우, id(x) 는 x 가 저장된 메모리의 주소입니다.

객체의 형은 객체가 지원하는 연산들을 정의하고 (예를 들어, "길이를 갖고 있나?") 그 형의 객체들이 가질 수 있는 가능한 값들을 정의합니다. type() 함수는 객체의 형(이것 역시 객체다)을 돌려줍니다. 아이덴티티와 마찬가지로, 객체의 형 (type) 역시 변경되지 않습니다. 1

flowdas

객체의 형 역시 객체라면, 그 객체의 형은 무엇인가? 이런 식으로 꼬리를 물고 올라갈 경우 "스스로 존재하는 자" 가 필요합니다. 즉 자신의 형이 자기 자신인 존재가 필요하다는 뜻입니다. 이 것이 type 입니다:

>>> type(type) is type
True

flowdas

객체의 형은 제한적이나마 변경될 수 있습니다. 예를 들어 인스턴스의 __class__ 어트리뷰트는 인스턴스 객체의 형(이 경우는 클래스가 됩니다)을 가리키는데, 대입이 가능합니다. 아무 값이나 대입할 수는 없지만, 다른 클래스를 대입할 수 있습니다. 변경 이후에는 type() 함수도 새 클래스를 돌려주고, 다른 부분에서도 새 클래스의 인스턴스 인 것처럼 동작합니다. 하지만 각주에서 권하는 것처럼 극히 예외적인 경우로 다뤄야할 것입니다.

어떤 객체들의 값 은 변경할 수 있습니다. 값을 변경할 수 있는 객체들을 가변(mutable) 이라고 합니다. 일단 만들어진 후에 값을 변경할 수 없는 객체들을 불변(immutable) 이라고 합니다. (가변 객체에 대한 참조를 저장하고 있는 불변 컨테이너의 값은 가변 객체의 값이 변할 때 변경된다고 볼 수도 있습니다; 하지만 저장하고 있는 객체들의 집합이 바뀔 수 없으므로 컨테이너는 여전히 불변이라고 여겨집니다. 따라서 불변성은 엄밀하게는 변경 불가능한 값을 갖는 것과는 다릅니다. 좀 더 미묘합니다.) 객체의 가변성(mutability)은 그것의 형에 의해 결정됩니다; 예를 들어 숫자, 문자열, 튜플(tuple)은 불변이지만, 딕셔너리(dictionary) 와 리스트(list)는 가변입니다.

객체는 결코 명시적으로 파괴되지 않습니다; 더 참조되지 않을 때(unreachable) 가비지 수거(garbage collect)됩니다. 구현이 가비지 수거를 지연시키거나 아예 생략하는 것이 허락됩니다 --- 아직 참조되는 객체들을 수거하지 않는 이상 가비지 수거가 어떤 식으로 구현되는지는 구현의 품질 문제입니다.

flowdas

del 키워드는 객체에 대한 참조를 지우는 것이지 객체를 명시적으로 파괴하는 것이 아닙니다. CPython 의 경우 참조를 지운 결과 카운트가 0 으로 떨어지면 즉시 수거되겠지만, 다른 곳에서 참조가 되고 있는 경우 카운트가 0 으로 떨어지지 않기 때문에 수거되지 않습니다. 다른 참조들을 모두 제거하기 전에, 객체를 강제로 파괴할 수 있는 방법은 없습니다.

CPython implementation detail: CPython 은 현재 참조 횟수 계산(reference-counting) 방식을 사용하는데, (선택 사항으로) 순환적으로 연결된 가비지의 지연된 감지가 추가됩니다. 이 방법으로 대부분 객체를 참조가 제거되자마자 수거할 수 있습니다. 하지만 순환 참조가 있는 가비지들을 수거한다는 보장은 없습니다. 순환적 가비지 수거의 제어에 관한 정보는 gc 모듈 문서를 참조하면 됩니다. 다른 구현들은 다른 식으로 동작하고, CPython 도 변경될 수 있습니다. 참조가 제거될 때 즉각적으로 파이널리제이션(finalization)되는 것에 의존하지 말아야 합니다 (그래서 항상 파일을 명시적으로 닫아주어야 합니다).

flowdas

gc 모듈은 순환적 가비지 수거에 관해서만 관여합니다. CPython 의 경우 참조 횟수 계산은 언제나 일어나는 것이고, 중지 시킬 방법 같은 것은 없습니다.

flowdas

순환적 가비지 수거는 성능에 영향을 줍니다. (사실 대부분의 언어에서 가비지 수거는 늘 문제가 되는 부분입니다.) 만약 가비지들 간의 순환 참조가 발생하지 않거나, 관리 가능한 수준으로 유지할 수 있다면 아예 순환적 가비지 수거를 꺼버리는 것이 성능을 개선하는 경우가 있습니다. gc.disable() 로 끌 수 있습니다.

구현이 제공하는 추적이나 디버깅 장치의 사용은 그렇지 않으면 수거될 수 있는 객체들을 살아있도록 만들 수 있음에 주의해야 합니다. 또한 'try...except' 문으로 예외를 잡는 것도 객체를 살아있게 만들 수 있습니다.

어떤 객체들은 열린 파일이나 창 같은 "외부(external)" 자원들에 대한 참조를 포함합니다. 이 자원들은 객체가 가비지 수거될 때 반납된다고 이해되지만, 가비지 수거는 보장되는 것이 아니므로, 그런 객체들은 외부자원을 반납하는 명시적인 방법 또한 제공합니다. 보통 close() 메서드다. 프로그램을 작성할 때는 그러한 객체들을 항상 명시적으로 닫아야(close) 합니다. 'try...finally' 문과 'with' 문은 이렇게 하는 편리한 방법을 제공합니다.

flowdas

close() 메서드를 제공하는 대부분의 객체들은, 컨텍스트 관리자 프로토콜을 지원하기 때문에 'with' 문 만으로 쉽고 안전하게 관리할 수 있습니다. 하지만 close() 메서드만 지원하고 컨텍스트 관리자 프로토콜을 지원하지 않는다면, 'try...finally' 문 보다는 contextlib.closing() 과 'with' 문을 사용하는 것을 권합니다.

어떤 객체들은 다른 객체에 대한 참조를 포함하고 있습니다. 이런 것들을 컨테이너(container) 라고 부릅니다. 튜플, 리스트, 딕셔너리등이 컨테이너의 예입니다. 이 참조들은 컨테이너의 값의 일부입니다. 대부분은, 우리가 컨테이너의 값을 논할 때는, 들어있는 객체들의 아이덴티티 보다는 값을 따집니다. 하지만, 컨테이너의 가변성에 대해 논할 때는 직접 가진 객체들의 아이덴티티만을 따집니다. 그래서, (튜플 같은) 불변 컨테이너가 가변 객체로의 참조를 하고 있다면, 그 가변 객체가 변경되면 컨테이너의 값도 변경됩니다.

형은 거의 모든 측면에서 객체가 동작하는 방법에 영향을 줍니다. 객체의 아이덴티디가 갖는 중요성조차도 어떤 면에서는 영향을 받습니다: 불변형의 경우, 새 값을 만드는 연산은 실제로는 이미 존재하는 객체 중에서 같은 형과 값을 갖는 것을 돌려줄 수 있습니다. 반면에 가변 객체에서는 이런 것이 허용되지 않습니다. 예를 들어, a = 1; b = 1 후에, a 와 b 는 값 1을 갖는 같은 객체일 수도 있고, 아닐 수도 있습니다. 하지만 c = []; d = [] 후에, c 와 d 는 두 개의 서로 다르고, 독립적이고, 새로 만들어진 빈 리스트임이 보장됩니다. (c = d = [] 는 객은 객체를 c 와 d 에 대입합니다.)

flowdas

CPython 의 경우, a = 1; b = 1 후에, a 와 b 는 동일한 객체가 됩니다. 성능 개선을 위해 -5 에서 256 사이의 정수를 캐싱하기 때문입니다. 중요한 것은, 이런 세부 사항을 기억하는 것이 아니라, 이런 문제 때문에 불변형에 대해서 is 연산자를 사용할 때 조심해야한다는 것입니다.

3.2. 표준형 계층¶

아래에 파이썬에 내장된 형들의 목록이 있습니다. (구현에 따라 C 나 자바나 다른 언어로 작성된) 확장 모듈들은 추가의 형을 정의할 수 있습니다. 파이썬의 미래 버전 역시 형 계층에 형을 더할 수 있는데 (예를 들어, 유리수, 효율적으로 저장된 정수 배열 등등), 표준 라이브러리를 통해 추가될 가능성이 더 크기는 합니다.

아래에 나오는 몇몇 형에 대한 설명은 '특수 어트리뷰트(special attribute)' 를 나열하는 문단을 포함합니다. 이것들은 구현에 접근할 방법을 제공하는데, 일반적인 사용을 위한 것이 아닙니다. 정의는 앞으로 변경될 수 있습니다.

None

이 형은 하나의 값만을 갖습니다. 이 값을 갖는 하나의 객체가 존재합니다. 이 객체에는 내장된 이름 None 을 통해 접근합니다. 여러 가지 상황에서 값의 부재를 알리는 데 사용됩니다. 예를 들어, 명시적으로 뭔가를 돌려주지 않는 함수의 반환 값입니다. 논리값은 거짓입니다.

NotImplemented

이 형은 하나의 값만을 갖습니다. 이 값을 갖는 하나의 객체가 존재합니다. 이 객체에는 내장된 이름 NotImplemented 을 통해 접근합니다. 숫자 메서드(numeric method)와 비교(rich comparison) 메서드는 제공된 피연산자에 대해 연산이 구현되지 않으면 이 값을 돌려줘야 합니다. (그러면 인터프리터는 연산자에 따라 뒤집힌 연산이나, 어떤 다른 대안을 시도합니다.) 불리언 문맥에서 평가되지 않아야 합니다.

더 자세한 내용은 산술 연산 구현 을 참고하십시오.

flowdas

숫자 메서드란, 숫자 형 또는 숫자를 흉내내는 형에서 이항 산술 연산(binary arithmetic operation) (+, -, *, @, /, //, %, divmod(), pow(), **, <<, >>, &, ^, |) 의 기능을 제공하는 역할을 하는 다음과 같은 메서드들을 뜻합니다.

__add__()
__sub__()
__mul__()
__matmul__()
__truediv__()
__floordiv__()
__mod__()
__divmod__()
__pow__()
__lshift__()
__rshift__()
__and__()
__xor__()
__or__()

이 메서드들이 NotImplemented 를 돌려주면 해당 구현이 존재하지 않는 것으로 보고 뒤집힌 연산을 시도합니다. 뒤집힌 연산은 위에 나열한 메서드들의 이름에 r 접두어를 붙인 것들입니다.

예를들어 x + y 라는 표현식이 있을 때, x 가 __add__() 를 정의하고 있다면 먼저 x.__add__(y) 를 시도합니다. 정의 되어 있지 않거나 NotImplemented 를 돌려주면, y.__radd__(x) 를 시도합니다. 이렇게 하는 이유는 x 와 y 의 형이 다를 수 있기 때문입니다.(실제로 x 와 y 의 형이 같으면 __radd__() 는 사용되지 않습니다.)

가령 분수를 표현하는 형을 하나 추가했고, 객체 y 를 만들었다고 합시다. 당연히 분수는 정수와 더할 수 있을 것이기 때문에, y + x 라는 표현이 정수가 더해진 새 분수를 돌려주도록 __add__() 를 정의해줄 수 있습니다. 그런데 x + y 라는 표현도 같은 결과를 돌려주어야 하지만, 내장된 정수형이 새로 만든 분수형 y 와 더하는 방법을 알리가 없습니다. 이 때 정수형은 NotImplemented 를 돌려줍니다. 분수형에 __radd__() 를 정의해 두었다면, 이 표현도 같은 결과를 줄 수 있습니다.

숫자 메서드를 구현할 때는, 앞으로 추가될 형들과의 호환을 위해, 형 검사를 수행하고 모르는 형이 올 경우 NotImplemeted 를 돌려주도록 코딩하는 것이 좋습니다.

뒤집힌 연산에서도 NotImplemented 를 돌려줄 수 있는데, 이 경우는 더이상 대안을 찾지 않고 최종적인 TypeError 를 일으킵니다.

flowdas

숫자 메서드에는, 앞의 두 유형 외에 증분 대입 연산자를 처리하는데 사용되는 것들이 있습니다. 접두어 i 를 붙여서 나타냅니다. 예를 들어 __iadd__() 는 += 연산을 제공합니다. (divmod() 연산은 대응하는 증분 대입이 없기 때문에 __idivmod__ 는 존재하지 않습니다.)

증분 대입 연산은 그 성격상 대응하는 뒤집힌 연산이 없습니다. 대신에 x += y 라는 문장을 x = x + y 라는 문장으로 변환해서 시도합니다. 때문에 x 에 __iadd__() 가 정의되지 않았거나 NotImplemented 를 돌려주면, x = x + y 를 시도하게 됩니다.

flowdas

증분 대입 연산 메서드는, 가변형의 경우 자신의 값을 수정한 후 self 를 돌려주는 것이 관례이고, 이 경우 아이덴티티의 변경(새로운 객체가 만들어진다는 의미)은 이루어지지 않습니다. 하지만 x = x + y 형으로 변환되는 경우, 아이덴티티가 바뀔 수 있음에 주의해야 합니다. 불변형인 경우는, 아이덴티티의 변경을 수반하는 것이 자연스럽기 때문에 혼란을 일으킬 가능성이 적습니다.

간혹 일으키기 쉬운 실수는 NotImplemented 와 이름이 비슷한 NotImplementedError (추상 메서드임을 가리키는데 사용하는 예외입니다) 를 돌려주는 것입니다. 이 경우 TypeError 예외를 일으키지 않고 좌변이 NotImplementedError 로 치환되게 됩니다.

flowdas

비교 메서드란, 두 값을 비교하는데 사용되는 비교 연산자(comparison operator) (<, <=, ==, !=, >, >=) 의 기능을 제공하는 역할을 하는, 다음과 같은 메서드들을 뜻합니다.

__lt__()
__le__()
__eq__()
__ne__()
__gt__()
__ge__()

3.0 이전의 파이썬에서는 값들 간의 대소 관계를 정수로 표현하는 __cmp__ 메서드를 지원했고, 이를 비교 메서드라고 불렀습니다. 하지만 대소 관계(ordering)가 정의될 수 없는 경우도, 동등 관계(equality)는 정의될 수 있는 경우가 있고, 두 경우 모두 지원되는 경우도 동등 관계가 대소 관계에 비해 적은 계산이 필요한 경우가 많아서, 각 비교 연산을 별개의 메서드로 지원하는 방법이 새로 도입되었습니다. 그 전의 __cmp__ 와 구분하기 위해 이 것들을 rich comparison 이라고 부릅니다. 하지만 파이썬 3.0 부터는 __cmp__ 가 지원되지 않고, 좋은 번역어를 발견할 수도 없어서, 그냥 비교 메서드라고 부르기로 합니다. 앞으로 비교라는 단어는 rich comparison 을 가리키는 것으로 보면 됩니다.

버전 3.9에서 변경: 불리언 문맥에서 NotImplemented를 평가하는 것은 폐지되었습니다. 현재는 참으로 평가되지만, DeprecationWarning를 방출합니다. 향후 버전의 파이썬에서는 TypeError를 발생시킬 것입니다.

Ellipsis

이 형은 하나의 값만을 갖습니다. 이 값을 갖는 하나의 객체가 존재합니다. 이 객체에는 리터럴 ... 이나 내장된 이름 Ellipsis 을 통해 접근합니다. 논리값은 참입니다.

numbers.Number

이것들은 숫자 리터럴에 의해 만들어지고, 산순 연산과 내장 산술 함수들이 결과로 돌려줍니다. 숫자 객체는 불변입니다; 한 번 값이 만들어지면 절대 변하지 않습니다. 파이썬의 숫자는 당연히 수학적인 숫자들과 밀접하게 관련되어 있습니다, 하지만 컴퓨터의 숫자 표현상의 제약을 받고 있습니다.

__repr__()과 __str__()로 계산되는 숫자 클래스의 문자열 표현에는 다음과 같은 특성이 있습니다:

클래스 생성자에 전달될 때 원래 숫자 값을 가진 객체를 생성하는 유효한 숫자 리터럴 입니다.
가능하면, 표현은 10진법입니다.
소수점 앞의 단일 0을 제외하고, 선행 0은 표시되지 않습니다.
소수점 뒤의 단일 0을 제외하고, 후행 0은 표시되지 않습니다.
부호는 숫자가 음수일 때만 표시됩니다.

파이썬은 정수, 실수, 복소수를 구분합니다:

numbers.Integral

이것들은 수학적인 정수 집합(양과 음)에 속하는 요소들을 나타냅니다.

두 가지 종류의 정수가 있습니다:

정수 (int): 이것은 (가상) 메모리가 허락하는 한, 제약 없는 범위의 숫자를 표현합니다. 시프트(shift)와 마스크(mask) 연산이 목적일 때는 이진 표현이 가정되고, 음수는 일종의 2의 보수(2's complement)로 표현되는데, 부호 비트가 왼쪽으로 무한히 확장된 것과 같은 효과를 줍니다.
불린 (bool): 이것은 논리값 거짓과 참을 나타냅니다. False 와 True 두 객체만 불린 형 객체입니다. 불린 형은 int 형의 자식형(subtype)이고, 대부분 상황에서 각기 0과1처럼 동작합니다. 예외는 문자열로 변환되는 경우인데, 각기 문자열 "False" 와 "True" 가 반환됩니다.

정수 표현 규칙은 음수가 포함된 시프트와 마스크 연산에 가장 의미 있는 해석을 제공하기 위한 것입니다.

flowdas

제약 없는 범위의 숫자를 지원한다고는 하지만 사실은 sys.maxsize 에 의해 제약이 가해집니다. 그러나, sys.maxsize 가 충분히 크기 때문에, 이 제약에 도달하기 전에 메모리 한계에 도달하게됩니다.

flowdas

2의 보수는 어떤 숫자를 큰 2의 거듭제곱수에서 뺀 값을 뜻합니다. 가령 8비트 공간에서 숫자 1의 2의 보수는 2**8 - 1 == 255 가 됩니다. 음수를 표현할 때 2의 보수를 사용한다는 것은, (계속 8비트 공간을 예로 들자면) -3 을 표현할 때, 그 양의 숫자 3(0b0000_0011) 의 2의 보수 253(0b1111_1101) 으로 표현한다는 뜻입니다. 이 값은 양의 숫자의 비트를 반전 시킨 후(0b11111100)에 1을 더한 값과 같습니다.

이 논리를 무한한 크기의 숫자로 확장하기위해, 양의 숫자 3을 비트 0 이 왼쪽에 무한히 붙어있다고 (0b0000...0000_0011) 상상해봅시다. ... 자리가 모두 0으로 채워져 있는 숫자입니다. 이제 비트를 반전시키고 1을 더하면 0b1111...1111_1101 이 됩니다. ... 자리는 모두 1로 채워진 것으로 바뀝니다. 이 개념 모델이 구현될 때, 그 방법은 구현마다 다를 수 있지만, 부호 비트(양수는 0, 음수는 1)를 유지하고, 꼭 필요한 크기의 정수 배열에 값을 저장한다는 점에서는 동일합니다. 그리고는 "무한" 에 해당하는 부분은 부호 비트와 동일한 비트로 채워져있다고 보는 것입니다. 더 큰 자리수가 필요할 때 이 가정을 물리적인 비트로 만듭니다.

flowdas

시프트(shift) 연산은 비트를 왼쪽이나 오른쪽으로 지정한 개수만큼 미는 것인데, 늘 부호가 유지됩니다. 어떤 숫자가 나올지는 앞에서 설명한 개념 모델을 떠올리면 쉽게 판단할 수 있습니다.

x << n 은 x * pow(2,n) 과 같고, x >> n 은 x // pow(2,n) 과 같습니다.

flowdas

마스크(mask) 연산은 &, |, ^ 연산자를 사용하는 연산을 뜻하는데, 정수의 경우 비트열로 변환한 후 비트별로 AND, OR, XOR 연산을 수행하는 것을 뜻합니다. 이 경우 부호 비트끼리 AND, OR, XOR 를 수행해 보면 결과의 부호를 쉽게 파악할 수 있습니다. 개념 모델의 "무한" 부분은 이 값의 반복이 됩니다. 나머지 비트들은 어렵지 않게 파악할 수 있습니다.

numbers.Real (float)

이것들은 기계 수준의 배정도(double precision) 부동 소수점 수를 나타냅니다. 허락되는 값의 범위와 오버플로의 처리에 관해서는 하부 기계의 설계(와 C 나 자바 구현)에 따르는 수밖에 없습니다. 파이썬은 단정도(single precision) 부동 소수점 수를 지원하지 않습니다; 이것들을 사용하는 이유가 되는 프로세서와 메모리의 절감은 파이썬에서 객체를 사용하는데 들어가는 비용과 상쇄되어 미미해집니다. 그 때문에 두 가지 종류의 부동 소수점 수로 언어를 복잡하게 만들만한 가치가 없습니다.

flowdas

허락되는 값의 범위는 sys.float_info 에서 제공됩니다.

flowdas

대부분의 경우 IEEE 754 를 따르고 있습니다. 이 경우 float 는 64비트로 표현됩니다.

flowdas

대부분의 플랫폼에서, 오버플로우를 일으키면, 예외를 일으키지 않고 math.inf 나 -math.inf 를 돌려줍니다. 이런 동작은 표준 라이브러리의 fpectl 모듈을 통해 일부 변경할 수 있지만, 보통 fpectl 모듈이 제거된 상태로 배포되는 경우가 많고, 파이썬 3.7 부터는 이 모듈이 아예 삭제되었습니다.

numbers.Complex (complex)

이것들은 기계 수준 배정도 부동 소수점 수의 쌍으로 복소수를 나타냅니다. 부동 소수점 수와 한계와 문제점을 공유합니다. 복소수 z 의 실수부와 허수부는, 읽기 전용 어트리뷰트 z.real 와 z.imag 로 꺼낼 수 있습니다.

시퀀스들

음이 아닌 정수로 인덱싱(indexing)될 수 있는 유한한 길이의 순서 있는 집합을 나타냅니다. 내장함수 len() 은 시퀀스가 가진 항목들의 개수를 돌려줍니다. 시퀀스의 길이가 n 일 때, 인덱스(index) 집합은 숫자 0, 1, ..., n-1을 포함합니다. 시퀀스 a 의 항목 i 는 a[i] 로 선택됩니다.

시퀀스는 슬라이싱도 지원합니다: a[i:j] 는 i <= k < j 를 만족하는 모든 항목 k 를 선택합니다. 표현식에서 사용될 때, 슬라이스는 같은 형의 시퀀스입니다. 인덱스 집합은 0에서 시작되도록 다시 번호 매겨집니다.

어떤 시퀀스는 세 번째 "스텝(step)" 매개변수를 사용하는 "확장 슬라이싱(extended slicing)"도 지원합니다: a[i:j:k] 는 x = i + n*k, n >= 0, i <= x < j 를 만족하는 모든 항목 x 를 선택합니다.

flowdas

마치 확장 슬라이싱을 지원하지 않는 시퀀스가 존재하는 것처럼 표현되었지만, 사실 파이썬에 내장된 시퀀스들은 모두 확장 시퀀스를 지원합니다. 지원하지 않을 가능성이 있는 것들은 사용자 정의 시퀀스들 뿐입니다.

flowdas

원래 확장 슬라이싱은 수치 계산용 라이브러리(NumPy 의 조상뻘 되는 것)를 만드는 그룹의 요청으로 들어온 기능 (가령 전치행렬(transposed matrix)은 스텝을 조작하는 것 만으로도 표현 가능합니다)이고, 그 당시에는 파이썬의 내장 시퀀스들이 오히려 확장 시퀀스를 지원하지 않고 있었습니다.

시퀀스는 불변성에 따라 구분됩니다

불변 시퀀스

불변 시퀀스 형의 객체는 일단 만들어진 후에는 변경될 수 없습니다. (만약 다른 객체로의 참조를 포함하면, 그 객체는 가변일 수 있고, 변경될 수 있습니다; 하지만, 불변 객체로부터 참조되는 객체의 집합 자체는 변경될 수 없습니다.)

다음과 같은 형들은 불변 시퀀스입니다:

문자열(Strings): 문자열은 유니코드 코드 포인트(Unicode code point)들을 표현하는 값들의 시퀀스입니다. U+0000 - U+10FFFF 범위의 모든 코드 포인트들은 문자열로 표현될 수 있습니다. 파이썬에는 char 형이 없습니다. 대신에 문자열에 있는 각 코드 포인트는 길이 1 인 문자열 객체로 표현됩니다. 내장 함수 ord() 는 코드 포인트를 문자열 형식에서 0 - 10FFFF 범위의 정수로 변환합니다; chr() 은 범위 0 - 10FFFF 의 정수를 해당하는 길이 1 의 문자열 객체로 변환합니다. str.encode() 는 주어진 텍스트 인코딩을 사용해서 str 을 bytes 로 변환하고, bytes.decode() 는 그 반대 작업을 수행합니다.
튜플(Tuples): 튜플의 항목은 임의의 파이썬 객체입니다. 두 개 이상의 항목으로 구성되는 튜플은 콤마로 분리된 표현식의 목록으로 만들 수 있습니다. 하나의 항목으로 구성된 튜플(싱글턴,singleton)은 표현식에 콤마를 붙여서 만들 수 있습니다(괄호로 표현식을 묶을 수 있으므로, 표현식 만으로는 튜플을 만들지 않습니다). 빈 튜플은 한 쌍의 빈 괄호로 만들 수 있습니다.
바이트열(Bytes): 바이트열(bytes) 객체는 불변 배열입니다. 항목은 8-비트 바이트인데, 0 <= x < 256 범위의 정수로 표현됩니다. 바이트 객체를 만들 때는 바이트열 리터럴(b'abc' 와 같은) 과 내장 bytes() 생성자(constructor)를 사용할 수 있습니다. 또한, 바이트열 객체는 decode() 메서드를 통해 문자열로 디코딩될 수 있습니다.

가변 시퀀스

가변 시퀀스는 만들어진 후에 변경될 수 있습니다. 서브스크립션(subscription)과 슬라이싱은 대입문과 del (삭제) 문의 대상으로 사용될 수 있습니다.

현재 두 개의 내장 가변 시퀀스형이 있습니다:

리스트(Lists): 리스트의 항목은 임의의 파이썬 객체입니다. 리스트는 콤마로 분리된 표현식을 대괄호 안에 넣어서 만들 수 있습니다. (길이 0이나 1의 리스트를 만드는데 별도의 규칙이 필요 없습니다.)
바이트 배열(Byte Arrays): 바이트 배열(bytearray) 객체는 가변 배열입니다. 내장 bytearray() 생성자로 만들어집니다. 가변이라는 것(그래서 해싱 불가능하다는 것)을 제외하고, 바이트 배열은 불변 바이트열( bytes) 객체와 같은 인터페이스와 기능을 제공합니다.

확장 모듈 array 는 추가의 가변 시퀀스 형을 제공하는데, collections 모듈 역시 마찬가지입니다.

집합 형들(Set types)

이것들은 중복 없는 불변 객체들의 순서 없고 유한한 집합을 나타냅니다. 인덱싱할 수 없습니다. 하지만 이터레이트할 수 있고, 내장 함수 len() 은 집합 안에 있는 항목들의 개수를 돌려줍니다. 집합의 일반적인 용도는 빠른 멤버십 검사(fast membership testing), 시퀀스에서 중복된 항목 제거, 교집합(intersection), 합집합(union), 차집합(difference), 대칭차집합(symmetric difference)과 같은 집합 연산을 계산하는 것입니다.

flowdas

이터레이트한다는 것은, 인덱싱할 수는 없어도, 집합이 갖고 있는 원소들을 중복 없고 빠짐 없이 하나씩 꺼내볼 수 있다는 뜻입니다.

집합의 원소들에는 딕셔너리 키와 같은 불변성 규칙이 적용됩니다. 숫자 형의 경우는 숫자 비교에 관한 일반 원칙이 적용된다는 점에 주의해야 합니다: 만약 두 숫자가 같다고 비교되면(예를 들어, 1 과 1.0), 그중 하나만 집합에 들어갈 수 있습니다.

flowdas

딕셔너리 키와 동일한 불변성 규칙이라 함은 해시가능성(hashability)을 뜻합니다. 객체가 __hash__() 메서드와 __eq__() 메서드를 제공할 때 해시가능하다고 합니다. 또한 두 메서드의 구현에는 두 개의 제약 조건이 더 붙는데, __hash__() 는 항상 같은 값을 제공해야 하고, __eq__() 가 True 를 돌려주면 언제나 두 객체의 __hash__() 도 동일한 값을 제공해야 한다는 것입니다. 이 때문에 대체로 해시 가능성은 불변성을 포함하는 경향이 있지만 언어에서 강제하는 것은 아닙니다. 가령 내장 불변형들이 해시 가능하고, 가변 내장 컨테이너들이 해시 가능하지 않다는 사실은 이 관례를 따르고 있지만, 사용자 정의형들은 가변성의 여부와 관계없이 기본적으로 해시 가능합니다. 이는 사용자 정의형들의 __hash__() 와 __eq__() 기본 구현이 값은 무시하고 아이덴티티만 고려하기 때문입니다.

flowdas

내장 불변 컨테이너가 무조건 적으로 해시 가능하지는 않습니다. 저장된 값들 역시 해시 가능해야 합니다. 가령 () 와 (1, 'a') 는 해시 가능하지만, (1, ['a']) 는 해시 가능하지 않습니다. 이는 불변성과 해시 가능성이 다른 조건임을 보여주는 한 예입니다.

flowdas

집합과 딕셔너리의 키에서 해시가능성을 요구하는 이유는, 둘 다 해시테이블(hashtable) 기반의 자료 구조인데, 해시값이 변경될 경우 해시테이블을 재배치할 수 있는 메커니즘이 없기 때문입니다.(있어봐야 부담만 커지고 실익이 없기 때문입니다.) 내장 불변 컨테이너들은 값 기반의 깊은 해싱(deep hashing)을 사용하는데, 이 조건이 모든 경우에 필요한 것은 아니고, 단지 __hash__() 가 언제나 같은 값을 주어야 하고, __eq__() 와 일관성이 있어야 하는데, 내장 불변형 컨테이너들은 __eq__() 에서 이미 깊은 비교(deep comparison)를 제공하고 있기 때문입니다.

현재 두 개의 내장 집합 형이 있습니다:

집합(Sets): 이것들은 가변 집합을 나타냅니다. 내장 set() 생성자로 만들 수 있고, add() 같은 메서드들을 사용해서 나중에 수정할 수 있습니다.

flowdas

중괄호 {} 를 쓰는 집합 리터럴을 사용해서 만들 수도 있습니다. 하지만 이 방법으로 빈 집합을 만들 수는 없습니다.
불변 집합(Frozen sets): 이것들은 불변 집합을 나타냅니다. 내장 frozenset() 생성자로 만들 수 있습니다. 불변 집합(frozenset)은 불변이고 해시 가능 하므로, 다른 집합의 원소나, 딕셔너리의 키로 사용될 수 있습니다.

매핑(Mappings)

이것들은 임의의 인덱스 집합으로 인덱싱되는 객체들의 유한한 집합을 나타냅니다. 인덱스 표기법(subscript notation) a[k] 는 매핑 a 에서 k 로 인덱스 되는 항목을 선택합니다; 이것은 표현식에 사용될 수도 있고, 대입이나 del 문장의 대상이 될 수도 있습니다. 내장 함수 len() 은 매핑에 포함된 항목들의 개수를 돌려줍니다.

현재 한 개의 내장 매핑 형이 있습니다:

딕셔너리(Dictionaries)

이것들은 거의 임의의 인덱스 집합으로 인덱싱되는 객체들의 유한한 집합을 나타냅니다. 키로 사용할 수 없는 것들은 리스트, 딕셔너리나 그 외의 가변형 중에서 아이덴티티가 아니라 값으로 비교되는 것들뿐입니다. 딕셔너리의 효율적인 구현이, 키의 해시값이 도중에 변경되지 않고 계속 같은 값으로 유지되도록 요구하고 있기 때문입니다. 키로 사용되는 숫자 형의 경우는 숫자 비교에 관한 일반 원칙이 적용됩니다: 만약 두 숫자가 같다고 비교되면(예를 들어, 1 과 1.0), 둘 다 같은 딕셔너리 항목을 인덱싱하는데 사용될 수 있습니다.

딕셔너리는 삽입 순서를 유지합니다, 키가 딕셔너리에 순차적으로 추가된 순서와 같은 순서로 생성됨을 뜻합니다. 기존 키를 교체해도 순서는 변경되지 않지만, 키를 제거했다가 다시 삽입하면 이전 위치를 유지하는 대신 끝에 추가됩니다.

딕셔너리는 가변입니다; {...} 표기법으로 만들 수 있습니다 (딕셔너리 디스플레이 섹션을 참고하십시오).

확장 모듈 dbm.ndbm 과 dbm.gnu 는 추가의 매핑 형을 제공하는데, collections 모듈 역시 마찬가지입니다.

버전 3.7에서 변경: 딕셔너리는 3.6 이전의 파이썬 버전에서 삽입 순서를 유지하지 않았습니다. CPython 3.6에서, 삽입 순서가 유지되었지만, 그 시점에는 언어 보증이 아니라 구현 세부 사항으로 간주하였습니다.

콜러블(Callable types)

이것들은 함수 호출 연산(호출 섹션 참고)이 적용될 수 있는 형들입니다:

사용자 정의 함수

사용자 정의 함수 객체는 함수 정의를 통해 만들어집니다 (함수 정의 섹션 참고). 함수의 형식 매개변수(formal parameter) 목록과 같은 개수의 항목을 포함하는 인자(argument) 목록으로 호출되어야 합니다.

특수 어트리뷰트들(Special attributes):

어트리뷰트	의미
`__doc__`	함수를 설명하는 문자열 또는 없는 경우 `None`; 서브 클래스로 상속되지 않습니다.	쓰기 가능
`__name__`	함수의 이름.	쓰기 가능
`__qualname__`	함수의 정규화된 이름. 버전 3.3에 추가.	쓰기 가능
`__module__`	함수가 정의된 모듈의 이름 또는 (없는 경우) `None`	쓰기 가능
`__defaults__`	인자의 기본값 또는 (없는 경우) None 으로 만들어진 튜플.	쓰기 가능
`__code__`	컴파일된 함수의 바디(body) 를 나타내는 코드 객체	쓰기 가능
`__globals__`	함수의 전역 변수들을 가진 딕셔너리에 대한 참조 --- 함수가 정의된 모듈의 전역 이름 공간(namespace)	읽기 전용
`__dict__`	임의의 함수 어트리뷰트를 지원하는 이름 공간.	쓰기 가능
`__closure__`	`None` 또는 함수의 자유 변수(free variable)들에 대한 연결을 가진 셀(cell)들의 튜플. `cell_contents` 어트리뷰트에 대한 정보는 아래를 보십시오.	읽기 전용
`__annotations__`	매개변수의 어노테이션을 가진 dict. dict의 키는 매개변수의 이름인데, 반환 값 어노테이션이 있다면 `'return'` 을 키로 사용합니다.	쓰기 가능
`__kwdefaults__`	키워드 형태로만 전달 가능한 매개변수들의 기본값을 가진 dict.	쓰기 가능

"쓰기 가능" 하다고 표시된 대부분의 어트리뷰트들은 값이 대입될 때 형을 검사합니다.

함수 객체는 임의의 어트리뷰트를 읽고 쓸 수 있도록 지원하는데, 예를 들어 함수에 메타데이터(metadata)를 붙이는데 사용될 수 있습니다. 어트리뷰트를 읽거나 쓸 때는 일반적인 점 표현법(dot-notation)이 사용됩니다. 현재 구현은 오직 사용자 정의 함수만 함수 어트리뷰트를 지원함에 주의해야 합니다. 내장 함수의 함수 어트리뷰트는 미래에 지원될 수 있습니다.

셀 객체는 cell_contents 어트리뷰트를 가지고 있습니다. 셀의 값을 읽을 뿐만 아니라 값을 설정하는 데도 사용할 수 있습니다.

함수 정의에 관한 추가적인 정보를 코드 객체로부터 얻을 수 있습니다. 아래에 나오는 내부 형의 기술을 참고하십시오. 셀 형은 types 모듈에서 액세스할 수 있습니다.

flowdas

REPR 환경에서 정의된 경우 보통 __module__ 은 None 입니다.

flowdas

다른 함수 내에서 정의되는 함수가, 전역도 지역도 아닌 변수를 사용하는 경우가 있습니다. 이 변수들을 자유 변수(free variable)라고 하는데, 이 때 이 변수들의 값이 셀(cell) 이라는 내부 객체에 보관됩니다. __closure__ 는 이 셀들의 목록을 튜플로 제공합니다. 예를 들면:

>>> def counter():
...     n = 0
...     def tick():
...         nonlocal n
...         n += 1
...         return n
...     return tick
...
>>> c = counter()
>>> counter.__closure__ is None
True
>>> c.__closure__
(<cell at 0x103e51b28: int object at 0x1009dcc60>,)
>>> c.__closure__[0].cell_contents
0
>>> c()
1
>>> c.__closure__[0].cell_contents
1

flowdas

모듈의 전역 함수로 정의되지 않은 함수들에 접근하기 위해서는, 다른 객체들을 거쳐야 할 수 있습니다. 가령 앞에 소개한 tick 도 그렇고, 클래스의 메서드로 정의되는 함수들도 그렇습니다. __qualname__ 은 함수에 접근하는데 필요한 이름들을 (모듈명은 제외하고) 모두 제공합니다. 반면 __name__ 은 함수의 이름만을 제공합니다. 앞의 예를 사용하면:

>>> counter.__name__
'counter'
>>> counter.__qualname__
'counter'
>>> c.__name__
'tick'
>>> c.__qualname__
'counter.<locals>.tick'
>>> class X:
...     def f(self): pass
...
>>> X.f.__name__
'f'
>>> X.f.__qualname__
'X.f'

flowdas

또 다른 예를 하나 들어보겠습니다:

>>> def f(n: int = 5, *args, kp=None) -> int:
...     return n
...
>>> f.__annotations__
{'n': <class 'int'>, 'return': <class 'int'>}
>>> f.__defaults__
(5,)
>>> f.__kwdefaults__
{'kp': None}

__annotations__ 는 형 정보가 지정된 인자들과 반환값의 형 정보를 제공합니다. __defaults__ 는 위치가 할당된 인자들의 기본 값들을 제공합니다. 튜플의 길이는 위치가 할당된 인자들의 개수와 일치합니다. 예에서 args 는 기본값을 가지는 것이 불가능하기 때문에 __defaults__ 에 할당되는 자리도 없습니다. *args 뒤에 오는 인자들은 위치가 지정되지 않고, 오직 키워드 형태로만 전달될 수 있습니다. 이 것들의 기본 값은 __kwdefaults__ 에 딕셔너리 형태로 제공됩니다.

이 값들은 단순한 정보가 아니고, 실제로 함수가 실행중에 사용하고 있는 값입니다. 때문에, 바꾸면 영향을 받습니다:

>>> f()
5
>>> f.__defaults__ = (9,)
>>> f()
9

인스턴스 메서드(Instance methods)

인스턴스 메서드는 클래스, 클래스 인스턴스와 모든 콜러블 객체 (보통 사용자 정의 함수)을 결합합니다.

특수 읽기 전용 어트리뷰트들: __self__ 는 클래스 인스턴스 객체, __func__ 는 함수 객체; __doc__ 은 메서드의 설명 (__func__.__doc__ 과 같습니다); __name__ 은 메서드의 이름 (__func__.__name__ 과 같습니다); __module__ 은 메서드가 정의된 모듈의 이름이거나 없는 경우 None.

flowdas

예를 들면:

>>> class C:
...     def f(self): return self
...
>>> i = C()
>>> i.f.__self__ is i
True
>>> i.f.__func__ is C.f # C.f 는 일반 사용자 정의 함수입니다.
True
>>> i.f.__name__ == i.f.__func__.__name__
True
>>> i.f.__func__.__name__ = 'g' # 기반 함수의 어트리뷰트는 쓰기가능합니다
>>> C.f.__name__ == 'g'
True
>>> i.f.__name__ == 'g' # 인스턴스 메서드는 기반 함수의 특수 어트리뷰트를 반영합니다
True
>>> i.f.__name__ = 'f'  # 인스턴스 메서드의 특수 어트리뷰트는 읽기전용입니다
Traceback (most recent call last):
  ...
AttributeError: 'method' object has no attribute '__name__'

메서드는 기반 함수의 모든 함수 어트리뷰트들을 읽을 수 있도록 지원합니다(하지만 쓰기는 지원하지 않습니다).

flowdas

앞의 예에서 계속됩니다:

>>> C.f.sample = True # 함수 어트리뷰트
>>> i.f.sample        # 함수 어트리뷰트는 인스턴스 메서드에도 따라옵니다
True
>>> i.f.sample = False # 하지만 인스턴스 메서드의 어트리뷰트에 쓸 수는 없습니다
Traceback (most recent call last):
  ...
AttributeError: 'method' object has no attribute 'sample'

어트리뷰트가 사용자 정의 함수 객체이거나 클래스 메서드 객체면, 사용자 정의 메서드 객체는 클래스의 어트리뷰트를 읽을 때 만들어질 수 있습니다 (아마도 그 클래스의 인스턴스를 통해서).

flowdas

예를 들면:

>>> class C:
...     def f(self):
...         return self
...     @classmethod
...     def g(cls):
...         return cls
...     @staticmethod
...     def h():
...         pass
...
>>> i = C()
>>> i.f is not C.f # 인스턴스 메서드는 새로 만들어지는 객체입니다
True
>>> i.g is not C.g # 클래스 메서드도 새로 만들어집니다
True
>>> i.h is not C.h # 하지만 스태틱 메서드는 새로 만들어지지 않습니다
False
>>> C.f is C.f # 클래스틀 통하면 사용자 정의 함수는 새로 만들어지지 않습니다
True
>>> C.h is C.h # 스태틱 메서드도 마찬가지입니다
True
>>> C.g is C.g # 하지만 클래스 메서드는 클래스를 통해 읽을 때도 새로 만들어집니다
True

인스턴스 메서드 객체가 클래스 인스턴스를 통해 클래스의 사용자 정의 함수 객체를 읽음으로써 만들어질 때, __self__ 어트리뷰트는 인스턴스이고, 메서드 객체는 결합(bound)하였다고 말합니다. 새 메서드의 __func__ 어트리뷰트는 원래의 함수 객체입니다.

flowdas

예를 들면:

>>> class C:
...     def f(self): return self
...
>>> i = C()
>>> i.f    # 인스턴스 메서드를 bound method 라고 부릅니다
<bound method C.f of <C object at 0x104f809b0>>
>>> i.f.__self__ is i # __self__ 는 연결된(bound) 인스턴스입니다
True
>>> i.f.__func__ is C.f # __func__ 는 원래의 함수 객체입니다
True

flowdas

조금 다른 예를 들면:

>>> class C:
...     def f(self):
...         return self
...     @classmethod
...     def g(cls):
...         return cls
...     @staticmethod
...     def h():
...         pass
...
>>> i = C()
>>> C.g is not C.g # 클래스 메서드는 클래스로 접근해도 새로 만들어집니다
True
>>> C.g # 클래스 메서드 역시 결합된 메서드입니다
<bound method C.g of <class 'C'>>
>>> C.g.__func__ # __func__ 는 일반 사용자 정의 함수 객체입니다
<function C.g at 0x10c4dc488>
>>> i.g.__func__ # 인스턴스 메서드의 __func__ 는 클래스 메서드 객체의 __func__ 로 연결됩니다
<function C.g at 0x10c4dc488>

인스턴스 메서드 객체가 클래스나 인스턴스로부터 클래스 메서드 객체를 읽음으로써 만들어질 때, __self__ 어트리뷰트는 클래스 자신이고, __func__ 어트리뷰트는 클래스 메서드가 기반을 두는 함수 객체입니다.

flowdas

앞의 예에서 계속됩니다:

>>> C.g.__self__ is C # 클래스 메서드의 __self__ 는 클래스입니다
True
>>> i.g.__self__ is C # 클래스 메서드로부터 만들어지는 인스턴스 메서드의 __self__ 역시 클래스입니다
True

인스턴스 메서드 객체가 호출될 때, 기반을 두는 함수 (__func__) 가 호출되는데, 인자 목록의 앞에 클래스 인스턴스 (__self__) 가 삽입됩니다. 예를 들어, C 가 함수 f() 의 정의를 포함하는 클래스이고, x 가 C 의 인스턴스일 때, x.f(1) 를 호출하는 것은 C.f(x, 1) 을 호출하는 것과 같습니다.

flowdas

앞의 예에서 계속됩니다:

>>> i.f() is i.     # 첫번째 인자로 __self__ 가 전달됩니다
True
>>> i.f() is C.f(i) # i.f() 와 C.f(i) 는 같은 결과를 줍니다.
True
>>> i.g() is C.     # 클래스 메서드는 __self__ 가 클래스입니다
True
>>> i.g() is C.g(). # 클래스 메서드는 i.g() 와 C.g() 가 같은 결과를 줍니다. C.g 도 결합된 메서드입니다
True

인스턴스 메서드 객체가 클래스 메서드 객체로부터 올 때, __self__ 에 저장된 "클래스 인스턴스" 는 실제로는 클래스 자신입니다. 그래서 x.f(1) 이나 C.f(1) 을 호출하는 것은 f(C,1) 를 호출하는 것과 같습니다 (f 는 기반 함수입니다).

flowdas

앞의 예에서 계속됩니다:

>>> i.g() is i.g.__func__(C) # 클래스 메서드로 부터 온 인스턴스 메서드를 호출하는 것은 기반 함수에 클래스를 전달해서 호출하는 것과 같습니다.
True

함수 객체에서 인스턴스 객체로의 변환은 인스턴스로부터 어트리뷰트를 읽을 때마다 일어남에 주의해야 합니다. 어떤 경우에, 어트리뷰트를 지역 변수에 대입하고, 그 지역 변수를 호출하는 것이 효과적인 최적화가 됩니다. 또한, 이 변환이 사용자 정의 함수에 대해서만 발생함에 주의해야 합니다; 다른 콜러블 객체 (그리고 콜러블이 아닌 모든 객체)는 변환 없이 읽힙니다. 클래스 인스턴스의 어트리뷰트인 사용자 정의 함수는 결합한 메서드로 변환되지 않는다는 것도 중요합니다; 이 변환은 함수가 클래스 어트리뷰트일 때만 일어납니다.

flowdas

앞의 예에서 계속됩니다:

>>> i.f is not i.f # 인스턴스 메서드는 읽을 때마다 새로 만들어집니다.
True
>>> f = i.f # 인스턴스 메서드를 지역 변수에 저장해서 사용하면 성능을 개선할 수 있습니다
>>> f() is i
True
>>> import timeit
>>> timeit('i.f()', globals=locals())
0.136665727943182
>>> timeit('f()', globals=locals())
0.09192681103013456
>>> C.p = lambda self: self # 클래스 어트리뷰트로 사용자 정의 함수를 넣으면 메서드를 정의한 것과 같은 결과를 줍니다.
>>> i.p() is i # 마찬가지 변환이 일어납니다.
True
>>> def q(): pass
...
>>> i.q = q     # 인스턴스 어트리뷰트로 사용자 정의 함수를 넣으면
>>> i.q is q    # 변환이 일어나지 않습니다
True
>>> i.q() is None # 따라서 __self__ 도 전달되지 않습니다.
True

제너레이터 함수(Generator functions)

yield 문(yield 문 절 참조)을 사용하는 함수나 메서드를 제너레이터 함수 (generator function) 라고 부릅니다. 이런 함수를 호출하면 항상 이터레이터(iterator) 객체를 돌려주는데, 함수의 바디(body)를 실행하는 데 사용됩니다: 이터레이터의 iterator.__next__() 메서드를 호출하면 yield 문이 값을 제공할 때까지 함수가 실행됩니다. 함수가 return 문을 실행하거나 끝에 도달하면 StopIteration 예외를 일으키고, 이터레이터는 반환하는 값들의 끝에 도달하게 됩니다.

flowdas

이터레이터 프로토콜 이라는 것인데, iterator.__next__() 메서드를 직접 호출하기 보다는 다음과 같은 네가지 방법을 많이 사용합니다.

list, tuple, set 등 이터레이터를 받아들이는 컨테이너들의 생성자로 전달해서 변환
for 문
yield from 문
next() 내장 함수

next() 내장 함수를 사용하는 경우는 StopIteration 을 직접 처리해야 하고, 나머지 경우는 그러지 않아도 됩니다.

코루틴 함수(Coroutine functions)

async def 를 사용해서 정의되는 함수나 메서드를 코루틴 함수 (coroutine function) 라고 부릅니다. 이런 함수를 호출하면 코루틴 객체를 돌려줍니다. await 표현식을 비롯해, async with 와 async for 문을 사용할 수 있습니다. 코루틴 객체(Coroutine Objects) 섹션을 참조하십시오.

비동기 제너레이터 함수(Asynchronous generator functions)

async def 를 사용해서 정의되는 함수가 yield 문을 사용하면 비동기 제너레이터 함수 (asynchronous generator function) 라고 부릅니다. 이런 함수를 호출하면 항상 비동기 이터레이터(asynchronous iterator) 객체를 돌려주는데, 함수의 바디(body)를 실행하기 위해 async for 문에서 사용됩니다.

비동기 이터레이터의 aiterator.__anext__() 메서드를 호출하면 어웨이터블 을 돌려주는데, await 할 때 yield 문이 값을 제공할 때까지 함수가 실행됩니다. 함수가 빈 return 문을 실행하거나 끝에 도달하면 StopAsyncIteration 예외를 일으키고, 비동기 이터레이터는 반환하는 값들의 끝에 도달하게 됩니다.

내장 함수(Built-in functions)

내장 함수 객체는 C 함수를 둘러싸고 있습니다(wrapper). 내장 함수의 예로는 len() 과 math.sin() (math 는 표준 내장 모듈입니다) 가 있습니다. 인자의 개수와 형은 C 함수에 의해 결정됩니다. 특수 읽기 전용 어트리뷰트들: __doc__ 은 함수의 설명 문자열 또는 없는 경우 None 입니다; __name__ 은 함수의 이름입니다; __self__ 는 None 으로 설정됩니다 (하지만 다음 항목을 보십시오); __module__ 은 함수가 정의된 모듈의 이름이거나 없는 경우 None 입니다.

내장 메서드(Built-in methods)

이것은 사실 내장 함수의 다른 모습입니다. 이번에는 묵시적인 추가의 인자로 C 함수에 전달되는 객체를 갖고 있습니다. 내장 메서드의 예로는 alist.append() 가 있는데, alist 는 리스트 객체입니다. 이 경우에, 특수 읽기 전용 어트리뷰트 __self__ 는 alist 로 표현된 객체로 설정됩니다.

클래스(Classes)

클래스는 콜러블입니다. 이 객체들은 보통 자신의 새로운 인스턴스를 만드는 팩토리(factory)로 동작하는데, __new__() 메서드를 재정의(override)하는 클래스 형에서는 달라질 수도 있습니다. 호출 인자는 __new__() 로 전달되고, 일반적으로, 새 인스턴스를 초기화하기 위해 __init__() 로도 전달됩니다.

flowdas

__new__() 는 인스턴스 객체를 만드는데 사용되고, __init__() 는 그 객체를 초기화하는데 사용됩니다. 일반적으로는 __new__() 를 재정의하지 않는데, 이 경우 새 인스턴스가 만들어집니다. 하지만 특별한 목적으로 이를 재정의할 수 있습니다. 가령 클래스의 인스턴스가 오직 하나만 만들어지게 하고 싶다거나, 예전에 반납한 인스턴스들을 재활용 하고 싶다거나 하는 경우입니다. 이런 경우 언제나 새 인스턴스가 만들어진다고 보장할 수는 없고, 두 번 초기화될 가능성이 있기 때문에 __init__() 를 호출할지 여부를 결정하는 규칙이 존재합니다. 자세한 내용은 기본적인 커스터마이제이션 섹션에 나옵니다.

클래스 인스턴스(Class Instances)

클래스에서 __call__() 메서드를 정의함으로써, 클래스 인스턴스를 콜러블로 만들 수 있습니다.

모듈(Modules)

모듈은 파이썬 코드의 기본적인 조직화 단위이고, import 문이나, importlib.import_module() 과 내장 __import__() 함수를 호출해서 구동할 수 있는 임포트 시스템 에 의해 만들어집니다. 모듈 객체는 딕셔너리 객체로 구현되는 이름 공간을 갖습니다(이 딕셔너리 객체는 모듈에서 정의되는 함수들의 __globals__ 어트리뷰트로 참조됩니다). 어트리뷰트 참조는 이 딕셔너리에 대한 조회로 변환됩니다. 예를 들어, m.x 는 m.__dict__["x"] 와 같습니다. 모듈 객체는 모듈을 초기화하는데 사용된 코드 객체를 갖고 있지 않습니다 (일단 초기화가 끝나면 필요 없으므로).

어트리뷰트 대입은 모듈의 이름 공간 딕셔너리를 갱신합니다. 예를 들어, m.x = 1 은 m.__dict__["x"] = 1 과 같습니다.

미리 정의된 (쓰기 가능한) 어트리뷰트들: __name__ 은 모듈의 이름입니다; __doc__ 은 모듈의 설명 문자열 또는 없는 경우 None 입니다; (없을 수도 있는) __annotations__ 는 모듈의 바디를 실행하면서 수집된 변수 어노테이션 들을 담은 딕셔너리입니다; __file__ 은 모듈이 로드된 파일의 경로명입니다. 인터프리터에 정적으로 연결된 C 모듈과 같은 어떤 종류의 모듈들에서는 __file__ 어트리뷰트가 제공되지 않습니다; 공유 라이브러리(shared library)로부터 동적으로 로딩되는 확장 모듈의 경우 공유 라이브러리의 경로명이 제공됩니다.

특수 읽기 전용 어트리뷰트들: __dict__ 는 딕셔너리로 표현되는 모듈의 이름 공간입니다.

CPython implementation detail: CPython 이 모듈 딕셔너리를 비우는 방법 때문에, 딕셔너리에 대한 참조가 남아있더라도, 모듈이 스코프를 벗어나면 모듈 딕셔너리는 비워집니다. 이것을 피하려면, 딕셔너리를 복사하거나 딕셔너리를 직접 이용하는 동안은 모듈을 잡아두어야 합니다.

사용자 정의 클래스(Custom classes)

사용자 정의 클래스 형들은 보통 클래스 정의 때문에 만들어집니다 (클래스 정의 섹션 참조). 클래스는 딕셔너리로 구현된 이름 공간을 갖습니다. 클래스 어트리뷰트 참조는 이 딕셔너리에 대한 조회로 변환됩니다. 예를 들어, C.x 는 C.__dict__["x"] 로 변환됩니다 (하지만 어트리뷰트에 접근하는 다른 방법들을 허락하는 여러 가지 훅(hook)이 있습니다.). 거기에서 어트리뷰트 이름이 발견되지 않으면, 어트리뷰트 검색은 부모 클래스들에서 계속됩니다. 이 부모 클래스 검색은 C3 메서드 결정 순서(method resolution order)를 사용하는데, 다중 상속이 같은 부모 클래스로 모이는 '다이아몬드(diamond)' 계승 구조가 존재해도 올바르게 동작합니다. 파이썬이 사용하는 C3 MRO에 관한 좀 더 자세한 내용은 2.3 배포에 첨부된 문서 https://www.python.org/download/releases/2.3/mro/ 에서 찾아볼 수 있습니다.

클래스 어트리뷰트 참조가 (클래스 C 라고 하자) 클래스 메서드 객체로 귀결될 때는, __self__ 어트리뷰트가 C 인 인스턴스 메서드 객체로 변환됩니다. 스태틱 메서드로 귀결될 때는, 스태틱 메서드 객체가 감싸고 있는 객체로 변환됩니다. 클래스로부터 얻은 어트리뷰트가 __dict__ 에 저장된 값과 달라지도록 만드는 다른 방법이 디스크립터 구현하기 섹션에 나옵니다.

flowdas

"스태틱 메서드 객체가 감싸고 있는 객체"는 기반 함수를 뜻합니다. 즉 원래 함수가 스태틱 메서드 객체라는 껍데기를 벗고 그대로 제공됩니다. 그럼에도 불구하고 껍데기를 씌워두는 것은 인스턴스를 통해 어트리뷰트를 참조할 경우 때문입니다. 껍데기를 씌워두지 않으면 일반적인 인스턴스 메서드로 변환되기 때문에, 이를 막고자, 스태틱 메서드라는 껍데기를 씌워둔 후에, 클래스나 인스턴스 어느쪽이건 어트리뷰트에 접근하면 껍데기를 벗겨서 돌려줍니다.

이런 변환 없이 클래스 어트리뷰트에 저장된 원본(클래스 메서드는 클래스 메서드 인스턴스, 스태틱 메서드는 스태틱 메서드 인스턴스)을 조회하려면, 클래스의 __dict__ 어트리뷰트에서 꺼내면 됩니다. 다만 이 곳에는 부모 클래스가 제공하는 어트리뷰트는 들어있지 않습니다.

클래스 어트리뷰트 대입은 클래스의 딕셔너리를 갱신할 뿐, 어떤 경우도 부모 클래스의 딕셔너리를 건드리지는 않습니다.

클래스 객체는 클래스 인스턴스를 돌려주도록(아래를 보십시오) 호출될 수 있습니다(위를 보십시오).

특수 어트리뷰트들:__name__ 은 클래스의 이름입니다. __module__ 은 클래스가 정의된 모듈의 이름입니다. __dict__ 는 클래스의 이름 공간을 저장하는 딕셔너리입니다; __bases__ 는 부모 클래스들을 저장하는 튜플입니다; 부모 클래스 목록에 나타나는 순서를 유지합니다; __doc__ 은 클래스의 설명 문자열 이거나 정의되지 않으면 None 입니다; (없을 수 있는) __annotations__ 는 클래스의 바디를 실행하면서 수집된 변수 어노테이션 들을 담은 딕셔너리입니다.

클래스 인스턴스(Class instances)

클래스 인스턴스는 클래스 객체를 호출해서 (위를 보십시오) 만들어집니다. 클래스 인스턴스는 딕셔너리로 구현되는 이름 공간을 갖는데, 어트리뷰트를 참조할 때 가장 먼저 검색되는 곳입니다. 그곳에서 어트리뷰트가 발견되지 않고, 인스턴스의 클래스가 그 이름의 어트리뷰트를 갖고 있으면, 클래스 어트리뷰트로 검색이 계속됩니다. 만약 발견된 클래스 어트리뷰트가 사용자 정의 함수면, __self__ 어트리뷰트가 인스턴스인 인스턴스 메서드로 변환됩니다. 스태틱 메서드와 클래스 메서드 객체 또한 변환됩니다. 위의 "사용자 정의 클래스(Custom Classes)" 부분을 보십시오. 클래스로부터 얻은 어트리뷰트가 클래스의 __dict__ 에 저장된 값과 달라지도록 만드는 다른 방법이 디스크립터 구현하기 섹션에 나옵니다. 만약 클래스 어트리뷰트도 발견되지 않고, 클래스가 __getattr__() 메서드를 가지면, 조회를 만족시키기 위해 그 메서드를 호출합니다.

어트리뷰트 대입과 삭제는 인스턴스의 딕셔너리를 갱신할 뿐, 결코 클래스의 딕셔너리를 건드리지 않습니다. 만약 클래스가 __setattr__() 이나 __delattr__() 메서드를 가지면, 인스턴스의 딕셔너리를 갱신하는 대신에 그 메서드들을 호출합니다.

어떤 특별한 이름들의 메서드들을 가지면, 클래스 인스턴스는 숫자, 시퀀스, 매핑인 척할 수 있습니다. 특수 메서드 이름들 섹션을 보십시오.

특수 어트리뷰트들: __dict__ 는 어트리뷰트 딕셔너리입니다; __class__ 는 인스턴스의 클래스입니다.

I/O 객체 (파일 객체라고도 알려져 있습니다)

파일 객체 는 열린 파일을 나타냅니다. 파일 객체를 만드는 여러 가지 단축법이 있습니다: open() 내장 함수, os.popen(), os.fdopen() 과 소켓 객체의 makefile() 메서드 (그리고, 아마도 확장 모듈들이 제공하는 다른 함수들이나 메서드들).

sys.stdin, sys.stdout, sys.stderr 는 인터프리터의 표준 입력, 출력, 에러 스트림으로 초기화된 파일 객체들입니다; 모두 텍스트 모드로 열려서 io.TextIOBase 추상 클래스에 의해 정의된 인터페이스를 따릅니다.

내부 형(Internal types)

인터프리터가 내부적으로 사용하는 몇몇 형들은 사용자에게 노출됩니다. 인터프리터의 미래 버전에서 이들의 정의는 변경될 수 있지만, 완전함을 위해 여기서 언급합니다.

코드 객체(Code objects)

코드 객체는 바이트로 컴파일된(byte-compiled) 실행 가능한 파이썬 코드를 나타내는데, 그냥 바이트 코드 라고도 부릅니다. 코드 객체와 함수 객체 간에는 차이가 있습니다; 함수 객체는 함수의 전역 공간(globals) (함수가 정의된 모듈)을 명시적으로 참조하고 있지만, 코드 객체는 어떤 문맥(context)도 갖고 있지 않습니다; 또한 기본 인자값들이 함수 객체에 저장되어 있지만 코드 객체에는 들어있지 않습니다 (실행 시간에 계산되는 값들을 나타내기 때문입니다). 함수 객체와는 달리, 코드 객체는 불변이고 가변 객체들에 대한 어떤 참조도 (직접 혹은 간접적으로도) 갖고 있지 않습니다.

특수 읽기 전용 어트리뷰트들: co_name 은 함수의 이름입니다; co_argcount 는 위치 인자들 (위치 전용 인자와 기본값이 있는 인자들도 포함됩니다)의 총 개수입니다; co_posonlyargcount 는 위치 전용 인자들 (기본값이 있는 인자들도 포함됩니다)의 개수입니다; co_kwonlyargcount 는 키워드 전용 인자들 (기본값이 있는 인자들도 포함됩니다)의 개수입니다; co_nlocals 는 함수가 사용하는 지역 변수들 (인자들을 포함합니다)의 개수입니다; co_varnames 는 지역 변수들의 이름을 담고 있는 튜플입니다(인자들의 이름이 먼저 나옵니다); co_cellvars 는 중첩된 함수들이 참조하는 지역 변수들의 이름을 담고 있는 튜플입니다; co_freevars 는 자유 변수(free variables)들의 이름을 담고 있는 튜플입니다; co_code 는 바이트 코드 명령 시퀀스를 나타내는 문자열입니다; co_consts 는 바이트 코드가 사용하는 리터럴을 포함하는 튜플입니다; co_names 는 바이트 코드가 사용하는 이름들을 담고 있는 튜플입니다; co_filename 은 컴파일된 코드를 제공한 파일의 이름입니다; co_firstlineno 는 함수의 첫 번째 줄 번호입니다; co_lnotab 은 바이트 코드에서의 위치를 줄 번호로 매핑하는 법을 문자열로 인코딩한 값입니다 (자세한 내용은 인터프리터의 소스 코드를 참고하십시오); co_stacksize 는 필요한 스택의 크기입니다; co_flags 는 인터프리터의 여러 플래그(flag)들을 정수로 인코딩한 값입니다.

다음과 같은 값들이 co_flags 를 위해 정의되어 있습니다: 함수가 가변 개수의 위치 인자를 받아들이기 위해 사용되는 *arguments 문법을 사용하면 비트 0x04 가 1이 됩니다; 임의의 키워드 인자를 받아들이기 위해 사용하는 **keywords 문법을 사용하면 비트 0x08 이 1이 됩니다; 비트 0x20 은 함수가 제너레이터일 때 설정됩니다.

퓨처 기능 선언 (from __future__ import division) 또한 코드 객체가 특정 기능이 활성화된 상태에서 컴파일되었는지를 나타내기 위해 co_flags 의 비트들을 사용합니다: 함수가 퓨처 division이 활성화된 상태에서 컴파일되었으면 비트 0x2000 이 설정됩니다; 비트 0x10 과 0x1000 는 예전 버전의 파이썬에서 사용되었습니다.

co_flags 의 다른 비트들은 내부 사용을 위해 예약되어 있습니다.

만약 코드 객체가 함수를 나타낸다면, co_consts 의 첫 번째 항목은 설명 문자열이거나 정의되지 않으면 None 입니다.

프레임 객체(Frame objects)

프레임 객체는 실행 프레임(execution frame)을 나타냅니다. 트레이스백 객체에 등장할 수 있고 (아래를 보십시오), 등록된 추적 함수로도 전달됩니다.

특수 읽기 전용 어트리뷰트들: f_back 은 이전 스택 프레임 (호출자 방향으로)을 가리키거나, 이게 스택의 바닥이라면 None; f_code 는 이 프레임에서 실행되는 코드 객체; f_locals 는 지역 변수를 조회하는데 사용되는 딕셔너리; f_globals 는 전역 변수에 사용됩니다; f_builtins 는 내장된(intrinsic) 이름들에 사용됩니다; f_lasti 는 정확한 바이트 코드 명령(instruction)을 제공합니다 (코드 객체의 바이트 코드 문자열에 대한 인덱스입니다).

특수 쓰기 가능 어트리뷰트들: f_trace 는, None 이 아니면, 코드 실행 중의 여러 이벤트로 인해 호출되는 함수입니다 (디버거에서 사용됩니다). 보통 이벤트는 각 새 소스 줄에서 발생합니다 - f_trace_lines를 False로 설정하면 이것을 비활성화할 수 있습니다.

구현은 f_trace_opcodes를 True로 설정하는 것으로 요청되는 옵코드(opcode) 당 이벤트를 허용할 수 있습니다. 추적 함수에 의해 발생 된 예외가 추적되는 함수로 빠져나오면 정의되지 않은 인터프리터 동작을 유발할 수 있음에 주의해야 합니다.

f_lineno 는 프레임의 현재 줄 번호입니다 --- 트레이스 함수(f_trace)에서 이 값을 쓰면 해당 줄로 점프합니다 (오직 가장 바닥 프레임에서만 가능합니다). 디버거는 f_lineno 를 쓰기 위한 점프 명령을 구현할 수 있습니다 (소위 Set Next Statement).

프레임 객체는 한가지 메서드를 지원합니다:

frame.clear()¶

이 메서드는 프레임이 잡은 지역 변수들에 대한 모든 참조를 제거합니다. 또한, 만약 프레임이 제너레이터에 속하면, 제너레이터가 종료됩니다(finalize). 이것은 프레임 객체가 관련된 참조 순환을 깨는 데 도움을 줍니다 (예를 들어, 예외를 잡아서 트레이스백을 추후 사용을 위해 저장할 때).

만약 프레임이 현재 실행 중이면 RuntimeError 예외가 발생합니다.

버전 3.4에 추가.

트레이스백 객체(Traceback objects)

트레이스백 객체는 예외의 스택 트레이스를 나타냅니다. 트레이스백 객체는 예외가 발생할 때 만들어지고, types.TracebackType 를 호출해서 명시적으로 만들 수도 있습니다.

묵시적으로 만들어진 트레이스백의 경우, 예외 처리기를 찾아서 실행 스택을 되감을 때, 각각 되감기 단계마다 현재 트레이스백의 앞에 트레이스백 객체를 삽입합니다. 예외 처리기에 들어가면, 스택 트레이스를 프로그램이 사용할 수 있습니다. (try 문 섹션 참조.) sys.exc_info() 가 돌려주는 튜플의 세 번째 항목이나 잡힌 예외의 __traceback__ 어트리뷰트로 액세스할 수 있습니다.

프로그램이 적절한 처리기를 제공하지 않는 경우, 스택 트레이스는 표준 에러 스트림으로 (보기 좋게 포맷되어) 출력됩니다; 만약 인터프리터가 대화형이면, sys.last_traceback 으로 사용자에게 제공합니다.

명시적으로 생성된 트레이스백의 경우, tb_next 어트리뷰트를 어떻게 연결하여 전체 스택 트레이스를 형성해야 하는지를 결정하는 것은 트레이스백을 만드는 주체에게 달려 있습니다.

특수 읽기 전용 어트리뷰트들: tb_frame 은 현 단계에서의 실행 프레임입니다; tb_lineno 는 예외가 발생한 줄의 번호를 줍니다; tb_lasti 정확한 바이트 코드 명령을 가리킵니다. 만약 예외가 except 절이나 finally 절이 없는 try 문에서 발생하면, 줄 번호와 트레이스백의 마지막 명령(last instruction)은 프레임 객체의 줄 번호와 다를 수 있습니다.

특수 쓰기 가능 어트리뷰트: tb_next 는 스택 트레이스의 다음 단계 (예외가 발생한 프레임 방향으로)이거나 다음 단계가 없으면 None 입니다.

버전 3.7에서 변경: 트레이스백 객체는 이제 파이썬 코드에서 명시적으로 인스턴스를 만들 수 있으며 기존 인스턴스의 tb_next 어트리뷰트를 변경할 수 있습니다.

슬라이스 객체(Slice objects)

슬라이스 객체는 __getitem__() 메서드를 위한 슬라이스를 나타냅니다. 내장 함수 slice() 로 만들 수도 있습니다.

특수 읽기 전용 어트리뷰트들: start 는 하한(lower bound) 입니다; stop 은 상한(upper bound) 입니다; step 은 스텝 값입니다; 각 값은 생략될 경우 None 입니다. 이 어트리뷰트들은 임의의 형이 될 수 있습니다.

슬라이스 객체는 하나의 메서드를 지원합니다.

slice.indices(self, length)¶: 이 메서드는 하나의 정수 인자 length 를 받아서 슬라이스 객체가 길이 length 인 시퀀스에 적용되었을 때 그 슬라이스에 대한 정보를 계산합니다. 세 개의 정수로 구성된 튜플을 돌려줍니다: 이것들은 각각 start 와 stop 인덱스와, step 또는 슬라이스의 스트라이드(stride) 길이입니다. 생략되었거나 범위를 벗어난 인덱스들은 일반적인 슬라이스와 같은 방법으로 다뤄집니다.

스태틱 메서드 객체(Static method objects)

스태틱 메서드 객체는 위에서 설명한 함수 객체를 메서드 객체로 변환하는 과정을 방지하는 방법을 제공합니다. 스태틱 메서드 객체는 다른 임의의 객체, 보통 사용자 정의 메서드를 둘러쌉니다. 스태틱 메서드가 클래스나 클래스 인스턴스로부터 읽힐 때 객체가 실제로 돌려주는 것은 둘러싸여 있던 객체인데, 다른 어떤 변환도 적용되지 않은 상태입니다. 둘러싸는 객체는 그렇더라도, 스태틱 메서드 객체 자체는 콜러블이 아닙니다. 스태틱 메서드 객체는 내장 staticmethod() 생성자로 만듭니다.

클래스 메서드 객체(Class method objects)

스태틱 메서드 객체처럼, 클래스 메서드 객체 역시 다른 객체를 둘러싸는데, 클래스와 클래스 인스턴스로부터 그 객체를 꺼내는 방식에 변화를 줍니다. 그런 조회에서 클래스 메서드 객체가 동작하는 방식에 대해서는 위 "사용자 정의 메서드(User-defined methods)" 에서 설명했습니다. 클래스 메서드 객체는 내장 classmethod() 생성자로 만듭니다.

3.3. 특수 메서드 이름들¶

클래스는 특별한 이름의 메서드들을 정의함으로써 특별한 문법 (산술 연산이나 인덱싱이나 슬라이딩 같은)에 의해 시작되는 어떤 연산들을 구현할 수 있습니다. 이것이 연산자 오버 로딩 (operator overloading)에 대한 파이썬의 접근법인데, 클래스가 언어의 연산자에 대해 자기 자신의 동작을 정의할 수 있도록 합니다. 예를 들어, 클래스가 __getitem__() 이라는 이름의 메서드를 정의하고, x 가 이 클래스의 인스턴스라면, x[i] 는 대략 type(x).__getitem__(x, i) 와 동등합니다. 언급된 경우를 제외하고, 적절한 메서드가 정의되지 않았을 때 연산은 예외를 일으킵니다 (보통 AttributeError 나 TypeError).

특수 메서드를 None 으로 설정하는 것은 해당 연산이 제공되지 않는다는 것을 가리킵니다. 예를 들어, 만약 클래스가 __iter__() 를 None 으로 설정하면, 클래스는 이터러블이 아닙니다. 따라서 이 인스턴스에 iter() 를 호출하면 TypeError 가 발생합니다. (__getitem__() 을 대안으로 시도하지 않습니다.) 2

내장형을 흉내 내는 클래스를 구현할 때, 모방은 모형화하는 객체에 말이 되는 수준까지만 구현하는 것이 중요합니다. 예를 들어, 어떤 시퀀스는 개별 항목들을 꺼내는 것만으로도 잘 동작할 수 있습니다. 하지만 슬라이스를 꺼내는 것은 말이 안 될 수 있습니다. (이런 한가지 예는 W3C의 Document Object Model의 NodeList 인터페이스입니다.)

3.3.1. 기본적인 커스터마이제이션¶

object.__new__(cls[, ...])¶

클래스 cls 의 새 인스턴스를 만들기 위해 호출됩니다. __new__() 는 스태틱 메서드입니다 (그렇게 선언하지 않아도 되는 특별한 경우입니다)인데, 첫 번째 인자로 만들려고 하는 인스턴스의 클래스가 전달됩니다. 나머지 인자들은 객체 생성자 표현(클래스 호출)에 전달된 것들입니다. __new__() 의 반환 값은 새 객체 인스턴스이어야 합니다 (보통 cls 의 인스턴스).

일반적인 구현은 super().__new__(cls[, ...]) 에 적절한 인자들을 전달하는 방법으로 슈퍼 클래스의 __new__() 를 호출해서 새 인스턴스를 만든 후에, 돌려주기 전에 필요한 수정을 가합니다.

flowdas

적절한 인자를 전달한다는 것은 super().__new__() 가 받을 수 있는 인자를 전달한다는 뜻이지, __new__() 로 전달된 모든 인자를 전달한다는 뜻이 아닙니다. __new__() 를 재정의 하는 클래스는 그 성격상 아무것도 계승하고 있지 않을(즉 object 만 계승할) 가능성이 많습니다. 이 때는 object.__new__() 가 호출되는데, 이 메서드는 cls 외에는 아무것도 받지 않습니다.

만약 __new__() 가 객체 생성 중에 호출되고, cls나 서브 클래스의 인스턴스를 돌려준다면, 새 인스턴스의 __init__() 메서드가 __init__(self[, ...]) 처럼 호출되는데, self 는 새 인스턴스이고, 나머지 인자들은 객체 생성자로 전달된 것들과 같습니다.

flowdas

만약 새로 인스턴스를 만들지 않고, 이미 존재하는 인스턴스를 돌려주려고 한다면, __init__() 가 두 번 호출될 수 있습니다.

만약 __new__() 가 cls 의 인스턴스를 돌려주지 않으면, 새 인스턴스의 __init__() 는 호출되지 않습니다.

flowdas

__new__() 가 None 을 돌려주면, 클래스 호출 자체의 결과가 None 이 됩니다. 때문에 클래스만으로도 팩토리 함수처럼 동작하도록 만들 수 있습니다.

__new__() 는 주로 불변형(int, str, tuple과 같은)의 서브 클래스가 인스턴스 생성을 커스터마이즈할 수 있도록 하는 데 사용됩니다. 또한, 사용자 정의 메타 클래스에서 클래스 생성을 커스터마이즈하기 위해 자주 사용됩니다.

flowdas

불변형은 일단 만들어진 후에는 수정할 수 없기 때문에, __init__() 에서 커스터마이즈 하기가 곤란합니다.

object.__init__(self[, ...])¶

(__new__() 에 의해) 인스턴스가 만들어진 후에, 하지만 호출자에게 돌려주기 전에 호출됩니다. 인자들은 클래스 생성자 표현으로 전달된 것들입니다. 만약 베이스 클래스가 __init__() 메서드를 갖고 있다면, 서브 클래스의 __init__() 메서드는, 있다면, 인스턴스에서 베이스 클래스가 차지하는 부분이 올바르게 초기화됨을 확실히 하기 위해 명시적으로 호출해주어야 합니다; 예를 들어: super().__init__([args...]).

flowdas

object.__init__() 가 정의되어 있기 때문에, 이 규칙은 사실상 모든 __init__() 는 항상 super().__init__([args...]) 를 호출해야 한다는 뜻이됩니다. 예를 들어봅시다. 세 개의 클래스가 다음과 같은 다중 계승 구조를 이루고 있습니다:

>>> class B1:
...     def __init__(self):
...         print('B1')
...
>>> class B2:
...     def __init__(self):
...         print('B2')
...
>>> class D(B1, B2):
...     def __init__(self):
...         print('D')
...         super().__init__()
...
>>> D()
D
B1
<D object at 0x10c70ff28>

B1 과 B2 가 이 규칙을 무시하고, super().__init__() 를 호출하지 않았습니다. object.__init__() 는 별다른 일을 하지 않기 때문에, B1 과 B2 자체를 사용하는데는 문제를 일으키지 않습니다. 하지만 이들을 다중 계승하는 다른 클래스에서 문제가 발생합니다. 이 경우 B2.__init__() 가 호출되지 않음을 볼 수 있습니다.

D.__init__() 에서 super().__init__() 대신에 B1.__init__() 와 B2.__init__() 를 차례대로 호출하면 되지 않겠는가 하고 생각할 수도 있지만, 이는 다른 문제를 만들게 되는데, 다음에 설명합니다. 이제 B1 과 B2 를 올바르게 구성해봅시다:

>>> class B1:
...     def __init__(self):
...         print('B1')
...         super().__init__()
...
>>> class B2:
...     def __init__(self):
...         print('B2')
...         super().__init__()
...
>>> class D(B1, B2):
...     def __init__(self):
...         print('D')
...         super().__init__()
...
>>> D()
D
B1
B2
<D object at 0x10c72a2b0>

D.__init__() 를 바꾸지 않았는데도, B2.__init__() 가 호출됨을 확인할 수 있습니다. 약간은 마술같은 일이 벌어졌는데, 모두 super() 때문에 일어나는 일입니다. super() 는 다음에 설명합니다.

flowdas

다중 계승에서 발생하는 진짜 문제는 소위 다이아몬드 계승이라는 것입니다. 가령 위의 예에서 B1 과 B2 가 같은 클래스 B 를 또 계승하고 있는 것입니다. 이 때 B.__init__() 가 정확히 한번만 호출되어야 합니다. 예를 들어봅시다:

>>> class B:
...     def __init__(self):
...         print('B')
...         super().__init__()
...
>>> class B1(B):
...     def __init__(self):
...         print('B1')
...         super().__init__()
...
>>> class B2(B):
...     def __init__(self):
...         print('B2')
...         super().__init__()
...
>>> class D(B1, B2):
...     def __init__(self):
...         print('D')
...         super().__init__()
...
>>> D()
D
B1
B2
B
<D object at 0x10c509208>

보시다시피, 언제나 super().__init__() 를 한번 호출한다는 규칙을 따르는 한 문제가 발생하지 않습니다. 하지만 만약 D.__init__() 가 super() 를 사용하지 않고, B1.__init__() 와 B2.__init__() 를 직접호출 하면 이런일이 발생합니다:

>>> class D(B1, B2):
... def __init__(self):
...     print('D')
...     B1.__init__(self)
...     B2.__init__(self)
...
>>> D()
D
B1
B2
B
B2
B
<D object at 0x10c509160>

B.__init__() 뿐만 아니라 B2.__init__() 도 두 번씩 호출되고 있습니다. 첫번째 B2.__init__() 는 B1.__init__() 가 호출한 것인데 super() 의 동작 원리 때문입니다. (이 역시 마술같은 일이지만, 이번에는 흑마술입니다.) 이처럼 다중 계승에서 super() 가 제공하는 메커니즘은 모든 클래스가 super() 를 사용하는 경우에만 올바로 동작합니다.

그러면 아예 super() 를 사용하지 않는다면? 그럴 경우는 B2.__init__() 가 두 번 호출되지는 않겠지만, B.__init__() 가 두 번 호출되는 것은 피할 수 없습니다.

flowdas

super() 는 이런 문제를 풀기 위한 특별한 메커니즘을 제공합니다. super() 는 다양한 방법으로 사용될 수 있지만, 지금의 경우에 국한한다면, 이런 일이 일어납니다.

super() 는 현재의 인스턴스(self) 의 __mro__ 어트리뷰트를 살핍니다. 이 값은 어떤 __init__() 가 실행되고 있는지에 관계 없이 (같은 self 가 전달되기 때문에) 같습니다. 또 한가지 살피는 것은 지금 __init__() 를 제공하는 클래스입니다. 즉 D.__init__() 에서 호출되는 super() 는 self 와 D 를 파악합니다.

이제 self.__mro__ 에서 D 를 검색해서 그 위치를 기억합니다. 이제 super().__init__() 를 호출하면, 먼저 super() 로부터 __init__ 라는 이름의 어트리뷰트를 요청해야하는데, super() 는 self.__mro__ 에서 현재 위치 다음에 나오는 클래스들 중에서 __init__ 를 제공하는 클래스를 찾아서 줍니다. self.__mro__ 의 끝에는 항상 object 가 들어있기 때문에 늘 object.__init__() 로 끝납니다.

이 메커니즘을 잘 따져보면, 언제나 한 방향으로만 검색하기 때문에 self.__mro__ 에 클래스가 두 번 등장하지 않는 이상, 한 클래스의 __init__() 가 두 번 호출될 일은 없습니다.

보통, 클래스를 정의할 때 이 순서가 결정됩니다. 이 순서를 MRO (method resolution order) 라고 부르는데, 베이스 클래스들의 계승 순서들을 따져서, 중복되지 않고 일관성있는 순서를 결정합니다. 인스턴스나 클래스의 어트리뷰트를 검색할 때도 같은 순서에 따라 검색합니다.

flowdas

그런데 한 가지 문제가 남아있습니다. super().__init__() 에 어떤 인자를 전달할 것인가 하는 문제입니다. 이 것이 문제가 되는 이유는, 어떤 클래스의 __init__() 가 호출되는지 정확히 알기 어렵기 때문입니다. 가령 위의 예에서 B1.__init__() 에 포함된 super().__init__() 는 B2.__init__() 를 호출하게 됩니다. 그런데 B1 을 작성하는 프로그래머는 B 에 대해서만 파악했을 뿐, B2 에 대해서는 들어본 일이 없을 수도 있습니다. B2 는 D 를 만드는 프로그래머가 새로 추가했을 수 있습니다. 그렇다면 B1 을 작성할 당시에는 B2.__init__() 가 어떤 인자를 필요로 하는지 알 길이 없습니다.

이 문제는 일관성있는 관례를 정하는 것 외에는 풀 길이 없는 문제입니다. 그 관례라 함은, 모두 같은 형식의 인자를 받아야 한다는 것입니다. 이는 설계의 문제인데, 클래스 계승 구조 전체에서 일관되게 사용될 수 있는 정책을 마련해야 합니다. 자주 사용되는 정책은, 아예 인자를 받지 않는 것과, 키워드 인자들만 받고 지원하지 않는 인자들은 모두 무시하는 것입니다. 결국 다승 계승 구조는 전체 적인 사전 설계가 필요한 작업이고, 특히 __init__() 가 정의된 클래스들을 사전 설계없이 다중 계승 구조에 병합하는 것은 문제를 일으킬 수 있습니다.

객체를 만드는데 __new__() 와 __init__() 가 협력하고 있으므로 (__new__() 는 만들고, __init__() 는 그것을 커스터마이즈합니다), __init__() 가 None 이외의 값을 돌려주면 실행시간에 TypeError 를 일으킵니다.

object.__del__(self)¶

인스턴스가 파괴되기 직전에 호출됩니다. 파이널라이저 또는 (부적절하게) 파괴자라고 불립니다. 만약 베이스 클래스가 __del__() 메서드를 갖고 있다면, 자식 클래스의 __del__() 메서드는, 정의되어 있다면, 인스턴스에서 베이스 클래스가 차지하는 부분을 적절하게 삭제하기 위해, 명시적으로 베이스 클래스의 메서드를 호출해야 합니다.

(권장하지는 않지만!) __del__() 메서드는 인스턴스에 대한 새로운 참조를 만듦으로써 인스턴스의 파괴를 지연시킬 수 있습니다. 이것을 객체 부활 이라고 부릅니다. 부활한 객체가 파괴될 때 __del__() 이 두 번째로 호출될지는 구현에 따라 다릅니다; 현재 CPython 구현은 오직 한 번만 호출합니다.

인터프리터가 종료할 때 아직 남아있는 객체들에 대해서는 __del__() 메서드의 호출이 보장되지 않습니다.

flowdas

__del__() 이 인스턴스의 파괴를 지연시키는 경우, CPython 3.4 이후로 __del__() 은 오직 한번만 호출됩니다. 파괴의 지연은 가능하지만 지연된 객체가 다시 파괴될 때는 __del__() 이 호출되지 않습니다. 자세한 내용은 PEP 442 를 참고하세요.

flowdas

__del__() 이 인스턴스의 파괴를 지연시키는 예를 들어보자면 이렇습니다:

>>> class X:
...     def __del__(self):
...         print('X.__del__')
...         global x
...         x = self
...
>>> x = X()
>>> del x
X.__del__
>>> del x
>>> del x
Traceback (most recent call last):
  ...
NameError: name 'x' is not defined

첫 번째 del x 에서 X.__del__() 이 호출되는데, 전역 변수 x 에 자신을 대입하기 때문에, 참조 회수가 0 이 되지 않도록 만듭니다. 때문에 실제로는 파괴되지 않고 살아있게 됩니다. 그래서 두 번째 del x 역시 정상 동작하고, 이 때 파괴가 실제로 일어나지만, X.__del__() 은 호출되지 않습니다. 이제 실제로 파괴되었기 때문에, 세번째 del x 는 예외를 일으키게 됩니다.

참고

del x 는 직접 x.__del__() 를 호출하지 않습니다 --- 앞에 있는 것은 x 의 참조 횟수(reference count)를 하나 감소시키고, 뒤에 있는 것은 x 의 참조 횟수가 0 이 될 때 호출됩니다.

CPython implementation detail: It is possible for a reference cycle to prevent the reference count of an object from going to zero. In this case, the cycle will be later detected and deleted by the cyclic garbage collector. A common cause of reference cycles is when an exception has been caught in a local variable. The frame's locals then reference the exception, which references its own traceback, which references the locals of all frames caught in the traceback.

gc 모듈에 대한 문서.

경고

__del__() 이 호출되는 불안정한 상황 때문에, 이것이 실행 중에 발생시키는 예외는 무시되고, 대신에 sys.stderr 로 경고가 출력됩니다. 특히:

__del__() 은 (임의의 스레드에서) 임의의 코드가 실행되는 동안 호출될 수 있습니다. __del__() 이 록을 얻어야 하거나 다른 블로킹 자원을 호출하면, __del__() 을 실행하기 위해 중단된 코드가 자원을 이미 차지했을 수 있으므로 교착 상태에 빠질 수 있습니다.
__del__() 은 인터프리터를 종료할 때 실행될 수 있습니다. 결과적으로, 액세스해야 하는 전역 변수(다른 모듈 포함)가 이미 삭제되었거나 None 으로 설정되었을 수 있습니다. 파이썬은 이름이 하나의 밑줄로 시작하는 전역 객체가 다른 전역 객체들보다 먼저 삭제됨을 보장합니다; 이것은, 만약 그 전역 객체들에 대한 다른 참조가 존재하지 않는다면, __del__() 메서드가 호출되는 시점에, 임포트된 모듈들이 남아있도록 확실히 하는 데 도움이 될 수 있습니다.

object.__repr__(self)¶

repr() 내장 함수에 의해 호출되어 객체의 "형식적인(official)" 문자열 표현을 계산합니다. 만약 가능하다면, 이것은 같은 (적절한 환경이 주어질 때) 값을 갖는 객체를 새로 만들 수 있는 올바른 파이썬 표현식처럼 보여야 합니다. 가능하지 않다면, <...쓸모있는 설명...> 형태의 문자열을 돌려줘야 합니다. 반환 값은 반드시 문자열이어야 합니다. 만약 클래스가 __str__() 없이 __repr__() 만 정의한다면, __repr__() 은 그 클래스 인스턴스의 "비형식적인(informal)" 문자열 표현이 요구될 때 사용될 수 있습니다.

이것은 디버깅에 사용되기 때문에, 표현이 풍부한 정보를 담고 모호하지 않게 하는 것이 중요합니다.

object.__str__(self)¶

str(object) 와 내장 함수 format(), print() 에 의해 호출되어 객체의 "비형식적인(informal)" 또는 보기 좋게 인쇄 가능한 문자열 표현을 계산합니다. 반환 값은 반드시 문자열 객체여야 합니다.

이 메서드는 __str__() 이 올바른 파이썬 표현식을 돌려줄 것이라고 기대되지 않는다는 점에서 object.__repr__() 과 다릅니다: 더 편리하고 간결한 표현이 사용될 수 있습니다.

내장형 object 에 정의된 기본 구현은 object.__repr__() 을 호출합니다.

object.__bytes__(self)¶: bytes 에 의해 호출되어 객체의 바이트열 표현을 계산합니다. 반환 값은 반드시 bytes 객체여야 합니다.

object.__format__(self, format_spec)¶

format() 내장 함수, 확대하면, 포맷 문자열 리터럴(formatted string literals) 의 계산과 str.format() 메서드에 의해 호출되어, 객체의 "포맷된" 문자열 표현을 만들어냅니다. format_spec 인자는 요구되는 포맷 옵션들을 포함하는 문자열입니다. format_spec 인자의 해석은 __format__() 을 구현하는 형에 달려있으나, 대부분 클래스는 포매팅을 내향형들의 하나로 위임하거나, 비슷한 포맷 옵션 문법을 사용합니다.

표준 포매팅 문법에 대해서는 포맷 명세 미니 언어 를 참고하면 됩니다.

반환 값은 반드시 문자열이어야 합니다.

버전 3.4에서 변경: object 의 __format__ 메서드 자신은, 빈 문자열이 아닌 인자가 전달되면 TypeError 를 발생시킵니다.

버전 3.7에서 변경: 이제 object.__format__(x, '') 는 format(str(x), '') 가 아니라 str(x) 와 동등합니다.

object.__lt__(self, other)¶

object.__le__(self, other)¶

object.__eq__(self, other)¶

object.__ne__(self, other)¶

object.__gt__(self, other)¶

object.__ge__(self, other)¶

이것들은 소위 "풍부한 비교(rich comparison)" 메서드입니다. 연산자 기호와 메서드 이름 간의 관계는 다음과 같습니다: x<y 는 x.__lt__(y) 를 호출합니다, x<=y 는 x.__le__(y) 를 호출합니다, x==y 는 x.__eq__(y) 를 호출합니다, x!=y 는 x.__ne__(y) 를 호출합니다, x>y 는 x.__gt__(y) 를 호출합니다, x>=y 는 x.__ge__(y) 를 호출합니다.

풍부한 비교 메서드는 주어진 한 쌍의 인자에게 해당 연산을 구현하지 않는 경우 단일자(singleton) NotImplemented 를 돌려줄 수 있습니다. 관례상, 성공적인 비교면 False 나 True 를 돌려줍니다. 하지만, 이 메서드는 어떤 형의 값이건 돌려줄 수 있습니다, 그래서 비교 연산자가 논리 문맥(Boolean context) (예를 들어 if 문의 조건)에서 사용되면, 파이썬은 결과의 참 거짓을 파악하기 위해 값에 대해 bool() 을 호출합니다.

flowdas

이 메서드가 어떤 형의 값이건 돌려줄 수 있도록 한 애초의 이유는, 벡터나 행렬과 같은 것들을 다루는 확장 모듈들을 지원하기 위해서입니다. 이런 모듈들에서 벡터간의 비교는 역시 항목들간의 비교값으로 구성된 벡터를 만들어냅니다. 하지만 이런 이런 용도로만 제한되지는 않습니다.

기본적으로, object는 is를 사용해서 거짓으로 비교될 때 NotImplemented를 반환하는 __eq__()를 구현합니다: True if x is y else NotImplemented. __ne__()의 경우는, 기본적으로 __eq__()에 위임하고 NotImplemented 가 아니라면 그 결과를 뒤집습니다. 비교 연산자나 기본 구현 간의 다른 암시적인 관계는 없습니다; 예를 들어, (x<y or x==y) 가 참이라고 해서 x<=y 가 참일 필요는 없습니다. 하나의 기본 연산으로부터 대소관계 연산을 자동으로 만들어내려면, functools.total_ordering()을 보십시오.

flowdas

__ne__() 를 구현하지 않아도 __eq__() 만 구현되어 있으면 x==y 뿐만 아니라 x!=y 역시 자동 지원되고, 그 값은 !(x==y) 가 된다는 뜻입니다. __ne__() 를 직접 구현한다면, 이 관계가 꼭 성립할 필요는 없습니다.

하지만 그 반대는 지원하지 않습니다. __eq__() 를 정의하지 않고, __ne__() 만 정의하는 경우, 여전히 x==y 가 지원되지만, 이 경우는 두 객체의 아이덴티티를 비교하는 기본 구현이 사용되는 것이지, !(x!=y) 로 변환된 것이 아닙니다.

flowdas

functools.total_ordering() 은 데코레이터로 사용되는데, 클래스에 이 데코레이터를 적용하면 __lt__(), __le__(), __gt__(), __ge__() 중에서 새로 정의한 것 하나를 골라 기본 연산으로 삼고, 빠진 것들을 기본 연산과 ==, !=, not, and, or 를 사용한 구현들로 채워넣습니다.

일반적으로 __eq__() 와 __lt__() 만 정의합니다. 이 때 객체들의 모든 값은 일관성있게 대소 비교(totally ordered)가 가능하게 됩니다. functools.total_ordering() 이 __eq__() 나 __lt__() 를 만들지는 않습니다.

사용자 정의 비교 연산자를 지원하고 딕셔너리 키로 사용될 수 있는 해시 가능 객체를 만드는 것에 관한 몇 가지 중요한 내용이 __hash__() 에 관한 문단에 나옵니다.

이 메서드들에 대한 (왼편의 인자는 연산을 지원하지 않지만, 오른편 인자가 지원할 때 사용되는) 뒤집힌 버전은 따로 없습니다; 대신에 __lt__() 와 __gt__() 는 서로의 뒤집힌 연산입니다; __le__() 와 __ge__() 는 서로의 뒤집힌 연산입니다; __eq__() 와 __ne__() 는 서로의 뒤집힌 연산입니다; 만약 피연산자가 서로 다른 형이고, 오른편 피연산자의 형이 왼편 피연산자의 형의 직간접적인 서브 클래스면, 오른편 피연산자의 뒤집힌 버전이 우선순위가 높습니다; 그렇지 않으면 왼편 피연산자의 메서드가 우선순위가 높습니다. 가상 서브 클래싱(virtual subclassing)은 고려되지 않습니다.

flowdas

두 피연산자 중 어느 하나의 형이 다른 하나의 형과 서브 클래스 관계에 있으면, 서브 클래스 쪽이 우선권을 가져서, 처음 부터 뒤집힌 연산이 먼저 시도된다는 뜻입니다.

이 규칙은 뒤집힌 버전이 따로 제공되는 산술 연산자에서도 적용됩니다.

flowdas

가상 서브클래싱(virtual subclassing) 이란, 소위 추상 베이스 클래스(ABC - Abstract Base Class)에서 사용되는 것인데, 클래스 정의에서 베이스 클래스를 정의하는 대신, ABC 의 abc.ABCMeta.register() 메서드를 사용해서 계승 관계를 정의해 주는 것을 뜻합니다.

object.__hash__(self)¶

내장 함수 hash() 와 set, frozenset, dict 와 같은 해시형 컬렉션의 멤버에 대한 연산에서 호출됩니다. __hash__() 는 정수를 돌려줘야 합니다. 같다고 비교되는 객체들이 같은 해시값을 가져야 한다는 성질만 요구됩니다. 객체의 비교에 사용되는 요소들로 튜플을 구성하고, 그 튜플의 해시값을 취함으로써 요소들의 해시값을 섞는 것을 권합니다. 예를 들면:

def __hash__(self):
    return hash((self.name, self.nick, self.color))

참고

hash() 는 객체가 정의한 __hash__() 메서드가 돌려주는 값을 Py_ssize_t 의 크기로 자릅니다(truncate). 이것은 보통 64-bit 빌드에서는 8바이트고, 32-bit 빌드에서는 4바이트입니다. 만약 객체의 __hash__() 가 서로 다른 비트 크기를 갖는 빌드들 사이에서 함께 사용되어야 한다면, 모든 지원할 빌드들에서의 폭을 검사해야 합니다. 이렇게 하는 쉬운 방법은 python -c "import sys; print(sys.hash_info.width)" 입니다.

만약 클래스가 __eq__() 를 정의하지 않으면 __hash__() 역시 정의하지 말아야 합니다. 만약 __eq__() 를 정의하지만 __hash__() 를 정의하지 않는다면, 그것의 인스턴스는 해시 가능 컬렉션에서 사용될 수 없습니다. 만약 클래스가 가변형 객체를 정의하고 있고 __eq__() 를 구현한다면, __hash__() 를 구현하지 말아야 하는데, 해시 가능 컬렉션들의 구현이 키의 해시값이 불변이도록 요구하고 있기 때문입니다(만약 객체의 해시값이 변하면, 잘못된 해시 버킷(hash bucket)에 있게 됩니다).

flowdas

두 객체가 같다고 비교될 경우 __hash__() 역시 같은 값을 주어야 한다는 조건과, 해시형 컬렉션들이 요구하는 키의 해시값이 불변이라는 조건을 합치면, 일단 해시형 컬렉션에서 키로 사용되기 위해서는 __eq__() 기준으로 불변이어야 한다는 뜻이됩니다. 이 때문에 가변형 객체에서 __eq__() 를 정의하는 경우, __hash__() 를 정의하지 말라고 하는 것입니다. 일단 __eq__() 가 정의되면 __hash__() 의 기본 구현이 제거되기 때문에, 해시형 컬렉션에서 사용할 수 없는 상태가 됩니다.

사용자 정의 클래스는 기본적으로 __eq__() 와 __hash__() 메서드를 갖습니다; 모든 객체는 (자기 자신을 제외하고) 같지 않다고 비교되고, x.__hash__() 는 적절한 값을 돌려주어, x == y 일 때 x is y 와 hash(x) == hash(y) 가 동시에 성립할 수 있도록 합니다.

__eq__() 를 재정의하고 __hash__() 를 정의하지 않는 클래스는 __hash__() 가 None 으로 설정됩니다. 클래스의 __hash__() 메서드가 None 이면, 클래스의 인스턴스는 프로그램이 해시값을 얻으려 시도할 때 TypeError 를 일으키고, isinstance(obj, collections.abc.Hashable) 로 검사할 때 해시 가능하지 않다고 올바로 감지됩니다.

flowdas

__eq__() 를 재정의하고 __hash__() 를 정의하지 않는 클래스에 대해 __hash__() 를 None 으로 설정하는 것은, 개별 클래스 정의마다 일어나는 일입니다. 부모 클래스의 정의가 어떠한지는 상관없습니다. __eq__() 를 정의하지 않으면 __hash__() 는 부모클래스로 부터 계승됩니다.

만약 __eq__() 를 재정의하는 클래스가 부모 클래스로부터 __hash__() 의 구현을 물려받고 싶으면 인터프리터에게 명시적으로 이렇게 지정해주어야 합니다: __hash__ = <ParentClass>.__hash__.

만약 __eq__() 를 재정의하지 않는 클래스가 해시 지원을 멈추고 싶으면, 클래스 정의에 __hash__ = None 을 포함해야 합니다. 자신의 __hash__() 을 정의한 후에 직접 TypeError 를 일으키는 경우는 isinstance(obj, collections.abc.Hashable) 호출이 해시 가능하다고 잘못 인식합니다.

참고

기본적으로, str과 bytes 객체들의 __hash__() 값은 예측할 수 없는 난수값으로 "솔트되어(salted)" 있습니다. 개별 파이썬 프로세스 내에서는 변하지 않는 값으로 유지되지만, 파이썬을 반복적으로 실행할 때는 예측할 수 없게 됩니다.

이것은 dict 삽입의 최악의 경우 성능(worst case performance), O(n^2) 복잡도, 을 활용하기 위해 주의 깊게 선택한 입력에 의한 서비스 거부(denial-of-service) 공격에 대한 방어를 제공하기 위한 목적입니다. 자세한 내용은 http://www.ocert.org/advisories/ocert-2011-003.html 에 있습니다.

해시값의 변경은 집합의 이터레이션 순서에 영향을 줍니다, 파이썬은 이 순서에 대해 어떤 보장도 하지 않습니다 (그리고 보통 32-bit 와 64-bit 빌드 사이에서도 다릅니다).

PYTHONHASHSEED 를 참고하십시오.

버전 3.3에서 변경: 해시 난수 화는 기본적으로 활성화됩니다.

object.__bool__(self)¶: 논리값 검사와 내장 연산 bool() 구현을 위해 호출됩니다; False 나 True 를 돌려줘야 합니다. 이 메서드가 정의되지 않는 경우, 정의되어 있다면 __len__() 이 호출되어, 값이 0 이 아니면 참으로 인식합니다. 만약 클래스가 __len__() 과 __bool__() 모두 정의하지 않는다면, 모든 인스턴스는 참으로 취급됩니다.

3.3.2. 어트리뷰트 액세스 커스터마이제이션¶

클래스 인스턴스의 어트리뷰트 참조(읽기, 대입하기, x.name 을 삭제하기)의 의미를 변경하기 위해 다음과 같은 메서드들이 정의될 수 있습니다.

object.__getattr__(self, name)¶

기본 어트리뷰트 액세스가 AttributeError 로 실패할 때 호출됩니다 (name 이 인스턴스 어트리뷰트 또는 self 의 클래스 트리에 있는 어트리뷰트가 아니라서 __getattribute__() 가 AttributeError 를 일으키거나; name 프로퍼티의 __get__() 이 AttributeError 를 일으킬 때). 이 메서드는 (계산된) 어트리뷰트 값을 반환하거나 AttributeError 예외를 일으켜야 합니다.

일반적인 메커니즘을 통해 어트리뷰트가 발견되면 __getattr__() 이 호출되지 않음에 주의해야 합니다 (이것은 __getattr__() 과 __setattr__() 간의 의도된 비대칭입니다). 이렇게 하는 이유는 효율 때문이기도 하고, 그렇게 하지 않으면 __getattr__() 가 인스턴스의 다른 어트리뷰트에 접근할 방법이 없기 때문이기도 합니다. 적어도 인스턴스 변수의 경우, 어떤 값도 인스턴스 어트리뷰트 딕셔너리에 넣지 않음으로써 (대신에 그것들을 다른 객체에 넣습니다) 완전한 제어인 것처럼 조작할 수 있습니다. 어트리뷰트 액세스를 실제로 완전히 조작하는 방법에 대해서는 아래에 나오는 __getattribute__() 에서 다룹니다.

flowdas

이미 존재하는 어트리뷰트의 경우, 대입할 때는 __setattr__() 가 호출되는데, 읽을 때는 __getattr__() 가 호출되지 않습니다.

__setattr__() 가 기능을 구현할 때는 다른 어트리뷰트를 대입하지 않고도 가능합니다. 가령 __setattr__() 는 __dict__ 에 직접 값을 넣을 수 있는데, __dict__ 의 내용을 바꾸는 것일뿐, __dict__ 라는 어트리뷰트 자체를 변경하는 것은 아닙니다. 이 때문에 __setattr__() 이 다시 __setattr__() 을 재귀적으로 호출하는 의도하지 않은 상황을 피할 수 있습니다.

하지만 어트리뷰트를 읽지 않고 __getattr__() 을 구현하는 것은, 특별한 경우라면 모를까 일반적으로 가능한 일은 아닙니다. 물론 예외 규칙을 도입하면 됩니다. 그 가장 간단한 예외 규칙 하나가, 이미 있는 어트리뷰트에 대해서는 __getattr__() 를 호출하지 않는다는 것입니다.

object.__getattribute__(self, name)¶

클래스 인스턴스의 어트리뷰트 액세스를 구현하기 위해 조건 없이 호출됩니다. 만약 클래스가 __getattr__() 도 함께 구현하면, __getattribute__() 가 명시적으로 호출하거나 AttributeError 를 일으키지 않는 이상 __getattr__ 는 호출되지 않습니다. 이 메서드는 어트리뷰트의 (계산된) 값을 돌려주거나 AttributeError 예외를 일으켜야 합니다. 이 메서드에서 무한 재귀(infinite recursion)가 발생하는 것을 막기 위해, 구현은 언제나 필요한 어트리뷰트에 접근하기 위해 같은 이름의 베이스 클래스의 메서드를 호출해야 합니다. 예를 들어, object.__getattribute__(self, name).

참고

언어 문법이나 내장 함수에 의한 묵시적인 호출이 결과로 특수 메서드를 참조하는 경우에는 이 메서드를 거치지 않을 수 있습니다. 자세한 내용은 특수 메서드 조회 에서 다룹니다.

인자 obj, name으로 감사 이벤트 object.__getattr__을 발생시킵니다.

object.__setattr__(self, name, value)¶

어트리뷰트 대입이 시도될 때 호출됩니다. 일반적인 메커니즘(즉 인스턴스 딕셔너리에 값을 저장하는 것) 대신에 이것이 호출됩니다. name 은 어트리뷰트 이름이고, value 는 그것에 대입하려는 값입니다.

__setattr__() 에서 인스턴스 어트리뷰트에 대입하려고 할 때는, 같은 이름의 베이스 클래스의 메서드를 호출해야 합니다. 예를 들어 object.__setattr__(self, name, value)

인자 obj, name, value로 감사 이벤트 object.__setattr__을 발생시킵니다.

object.__delattr__(self, name)¶

__setattr__() 과 비슷하지만 어트리뷰트를 대입하는 대신에 삭제합니다. 이것은 del obj.name 이 객체에 의미가 있는 경우에만 구현되어야 합니다.

인자 obj, name으로 감사 이벤트 object.__delattr__을 발생시킵니다.

object.__dir__(self)¶: 객체에 dir() 이 호출될 때 호출됩니다. 시퀀스를 돌려줘야 합니다. dir() 은 돌려준 시퀀스를 리스트로 변환한 후 정렬합니다.

3.3.2.1. 모듈 어트리뷰트 액세스 커스터마이제이션¶

특수한 이름 __getattr__ 과 __dir__ 는 모듈 어트리뷰트에 대한 접근을 사용자 정의하는 데 사용될 수도 있습니다. 모듈 수준의 __getattr__ 함수는 하나의 인자로 어트리뷰트의 이름을 받아서 계산된 값을 돌려주거나 AttributeError 를 발생시켜야 합니다. 일반적인 조회(즉 object.__getattribute__())를 통해 어트리뷰트가 모듈 객체에서 발견되지 않으면, AttributeError 를 일으키기 전에 모듈 __dict__ 에서 __getattr__ 을 검색합니다. 발견되면, 어트리뷰트 이름으로 그 함수를 호출하고 결과를 돌려줍니다.

__dir__ 함수는 인자를 받지 않고 모듈에서 접근 할 수 있는 이름을 나타내는 문자열의 시퀀스를 돌려줘야 합니다. 존재하면, 이 함수는 모듈에 대한 표준 dir() 검색을 재정의합니다.

모듈 동작(어트리뷰트 설정, 프로퍼티 등)을 보다 세밀하게 사용자 정의하려면, 모듈 객체의 __class__ 어트리뷰트를 types.ModuleType 의 서브 클래스로 설정할 수 있습니다. 예를 들면:

import sys
from types import ModuleType

class VerboseModule(ModuleType):
    def __repr__(self):
        return f'Verbose {self.__name__}'

    def __setattr__(self, attr, value):
        print(f'Setting {attr}...')
        super().__setattr__(attr, value)

sys.modules[__name__].__class__ = VerboseModule

참고

모듈 __getattr__ 정의와 모듈 __class__ 설정은 어트리뷰트 액세스 구문을 사용하는 조회에만 영향을 미칩니다 -- 모듈 전역에 대한 직접적인 액세스(모듈 내의 코드에 의한 액세스이거나 모듈의 전역 딕셔너리에 대한 참조를 거치거나)는 영향받지 않습니다.

버전 3.5에서 변경: 이제 __class__ 모듈 어트리뷰트가 쓰기 가능합니다.

버전 3.7에 추가: __getattr__ 과 __dir__ 모듈 어트리뷰트.

PEP 562 - 모듈 __getattr__ 과 __dir__: 모듈에 대한 __getattr__ 과 __dir__ 함수를 설명합니다.

3.3.2.2. 디스크립터 구현하기¶

다음에 오는 메서드들은 메서드를 가진 클래스(소위 디스크립터(descriptor) 클래스)의 인스턴스가 소유자(owner) 클래스에 등장할 때만 적용됩니다(디스크립터는 소유자 클래스의 딕셔너리나 그 부모 클래스 중 하나의 딕셔너리에 있어야 합니다). 아래의 예에서, "어트리뷰트" 는 이름이 소유자 클래스의 __dict__ 의 키로 사용되고 있는 어트리뷰트를 가리킵니다.

flowdas

이런 상황을 뜻합니다:

class Descriptor:
    def __get__(self, instance, owner):
        ...
    def __set__(self, instance, value):
        ...
    def __delete__(self, instance):
        ...
    def __set_name__(self, owner, name):
        ...

class Owner:
    attribute = Descriptor()

instance = Owner()

Descriptor 를 디스크립터 클래스라고 부르고, Owner 를 소유자 클래스라고 부릅니다. 디스크립터 클래스의 인스턴스가 소유자 클래스의 클래스 어트리뷰트로 들어간다는 것이 중요합니다. 이럴 때 Owner.attribute 나 instance.attribute 표현식을 계산하려고 하면 Descriptor.__get__() 이 끼어들게 됩니다.

object.__get__(self, instance, owner=None)¶

소유자 클래스(클래스 어트리뷰트 액세스) 나 그 클래스의 인스턴스(인스턴스 어트리뷰트 액세스)의 어트리뷰트를 취하려고 할 때 호출됩니다. 선택적 owner 인자는 소유자 클래스입니다. 반면에 instance 는 어트리뷰트 참조가 일어나고 있는 인스턴스이거나, 어트리뷰트가 owner 를 통해 액세스 되는 경우 None 입니다.

flowdas

위의 예에서 instance.attribute 는 Descriptor.__get__(self, instance, Owner) 가 호출되도록 하고, Owner.attribute 는 Descriptor.__get__(self, None, Owner) 이 호출되도록 한다는 뜻입니다. self 로는 Owner.__dict__['attribute'] 가 전달됩니다.

이 메서드는 계산된 어트리뷰트 값을 돌려주거나 AttributeError 예외를 일으켜야 합니다.

PEP 252는 __get__()이 하나나 두 개의 인자를 갖는 콜러블이라고 지정합니다. 파이썬 자신의 내장 디스크립터는 이 명세를 지원합니다; 그러나, 일부 제삼자 도구에는 두 인수를 모두 요구하는 디스크립터가 있을 수 있습니다. 파이썬 자신의 __getattribute__() 구현은 필요한지와 관계없이 항상 두 인자를 모두 전달합니다.

object.__set__(self, instance, value)¶

소유자 클래스의 인스턴스 instance 의 어트리뷰트를 새 값 value 로 설정할 때 호출됩니다.

flowdas

위의 예에서 instance.attribute = value 하는 경우입니다. __get__() 과 달리 클래스 어트리뷰트의 대입 Owner.attribute = value 는 디스크립터를 호출하지 않습니다.

__set__()이나 __delete__()를 추가하면 디스크립터 유형이 "데이터 디스크립터(data descriptor)"로 변경됨에 유의하십시오. 자세한 내용은 디스크립터 호출하기를 참조하십시오.

object.__delete__(self, instance)¶: 소유자 클래스의 인스턴스 instance 의 어트리뷰트를 삭제할 때 호출됩니다.

flowdas

위의 예에서 del instance.attribute 하는 경우입니다. __get__() 과 달리 클래스 어트리뷰트의 삭제 del Owner.attribute 는 디스크립터를 호출하지 않습니다.

object.__set_name__(self, owner, name)¶

소유자 클래스 owner 가 만들어질 때 호출됩니다. 이 디스크립터가 name 에 대입되었습니다.

flowdas

위의 예에서, Owner 클래스가 정의될 때, Descriptor.__set_name__(self, Owner, 'attribute') 가 호출됩니다.

flowdas

디스크립터는 자신이 어떤 이름의 클래스 어트리뷰트로 등록되었는지를 알면 유용한 경우가 많습니다. 가령 디스크립터는 데이터베이스 ORM 에서 컬럼을 표현할 때 자주 사용되는데, 자신이 어떤 이름의 컬럼에 매핑되어 있는지 알아야, 자신이 테이블의 어떤 컬럼에 매핑되는지 파악할 수 있습니다. 3.6 이전의 버전에서는 이 메서드가 제공되지 않았기 때문에 좀 더 복잡한 다른 방법(가령 메타클래스)으로 이 이름을 알아내곤 했습니다.

참고

__set_name__()은 type 생성자의 일부로 묵시적으로만 호출되므로, 초기 생성 이후에 디스크립터가 클래스에 추가될 때 적절한 매개 변수로 명시적으로 호출할 필요가 있습니다:

class A:
   pass
descr = custom_descriptor()
A.attr = descr
descr.__set_name__(A, 'attr')

더 자세한 내용은 클래스 객체 만들기 을 참고하십시오.

버전 3.6에 추가.

어트리뷰트 __objclass__ 는 inspect 모듈에 의해 이 객체가 정의된 클래스를 지정하는 것으로 해석됩니다(이 값을 적절히 설정하면 동적인 클래스 어트리뷰트의 실행시간 인트로스펙션(introspection)을 지원할 수 있습니다). 콜러블의 경우, 첫 번째 위치 인자에, 주어진 형(또는 서브 클래스)의 인스턴스가 기대되거나 요구됨을 가리킬 수 있습니다(예를 들어, CPython 은 C로 구현된 연결되지 않은 메서드(unbound method)에 이 어트리뷰트를 설정합니다).

flowdas

디스크립터 메서드의 경우 어트리뷰트 __objclass__ 를 inspect 모듈이 조사하기는 하지만, 그리 쓸모있는 역할을 하고 있지는 못합니다.

3.3.2.3. 디스크립터 호출하기¶

일반적으로, 디스크립터는 "결합한 동작(binding behavior)"을 가진 객체 어트리뷰트입니다. 어트리뷰트 액세스가 디스크립터 프로토콜(descriptor protocol)의 메서드들에 의해 재정의됩니다: __get__(), __set__(), __delete__(). 이 메서드들 중 하나라도 정의되어 있으면, 디스크립터라고 부릅니다.

어트리뷰트 액세스의 기본 동작은 객체의 딕셔너리에서 어트리뷰트를 읽고, 쓰고, 삭제하는 것입니다. 예를 들어 a.x 는 a.__dict__['x'] 에서 시작해서 type(a).__dict__['x'] 를 거쳐 type(a) 의 메타 클래스를 제외한 베이스 클래스들을 거쳐 가는 일련의 조회로 구성됩니다.

그러나, 만약 조회한 값이 디스크립터 메서드를 구현한 객체면, 파이썬은 기본 동작 대신에 디스크립터 메서드를 호출할 수 있습니다. 우선순위 목록의 어느 위치에서 이런 일이 일어나는지는 어떤 디스크립터 메서드가 정의되어 있고 어떤 식으로 호출되는지에 따라 다릅니다.

디스크립터 호출의 시작점은 결합(binding)입니다, a.x. 어떻게 인자들이 조합되는지는 a 에 따라 다릅니다:

직접 호출: 가장 간단하면서도 가장 덜 사용되는 호출은 사용자의 코드가 디스크립터 메서드를 직접 호출할 때입니다: x.__get__(a)
인스턴스 결합: 객체 인스턴스에 결합하면, a.x 는 이런 호출로 변환됩니다: type(a).__dict__['x'].__get__(a, type(a)).
클래스 결합: 클래스에 결합하면, A.x 는 이런 호출로 변환됩니다: A.__dict__['x'].__get__(None, A).
Super 결합: super 의 인스턴스에 결합하면, 결합 super(B, obj).m() 은 obj.__class__.__mro__ 를 검색해서 B 바로 다음에 나오는 베이스 클래스 A 를 찾은 후에 이렇게 디스크립터를 호출합니다: A.__dict__['m'].__get__(obj, obj.__class__).

인스턴스 결합의 경우, 디스크립터 호출의 우선순위는 어떤 디스크립터 메서드가 정의되어있는지에 따라 다릅니다. 디스크립터는 __get__(), __set__(), __delete__() 를 어떤 조합으로도 정의할 수 있습니다. 만약 __get__() 를 정의하지 않는다면, 어트리뷰트 액세스는, 객체의 인스턴스 딕셔너리에 값이 있지 않은 이상 디스크립터 객체 자신을 돌려줍니다. 만약 디스크립터가 __set__() 이나 __delete__() 중 어느 하나나 둘 다 정의하면, 데이터 디스크립터(data descriptor)입니다. 둘 다 정의하지 않는다면 비데이터 디스크립터(non-data descriptor)입니다. 보통, 데이터 디스크립터가 __get__() 과 __set__() 을 모두 정의하는 반면, 비데이터 디스크립터는 __get__() 메서드만 정의합니다. __get__() 과 __set__() (그리고/또는 __delete__()) 이 있는 데이터 디스크립터는 인스턴스 딕셔너리에 있는 값에 우선합니다. 반면에 비데이터 디스크립터는 인스턴스보다 우선순위가 낮습니다.

파이썬 메서드 (staticmethod() 와 classmethod() 를 포함해서) 는 비데이터 디스크립터로 구현됩니다. 이 때문에, 인스턴스는 메서드를 새로 정의하거나 덮어쓸 수 있습니다. 이것은 개별 인스턴스가 같은 클래스의 다른 인스턴스들과는 다른 동작을 얻을 수 있도록 만듭니다.

property() 함수는 데이터 디스크립터로 구현됩니다. 이 때문에, 인스턴스는 프로퍼티(property)의 동작을 변경할 수 없습니다.

3.3.2.4. slots¶

__slots__ 은 (프로퍼티처럼) 데이터 멤버를 명시적으로 선언하고 (__slots__ 에 명시적으로 선언하거나 부모로부터 물려받지 않는 한) __dict__ 와 __weakref__ 생성을 거부할 수 있도록 합니다.

__dict__ 를 사용할 때에 비교해 절약되는 공간은 상당할 수 있습니다. 어트리뷰트 조회 속도도 크게 개선할 수 있습니다.

object.__slots__¶: 이 클래스 변수에는 인스턴스에 의해 사용되는 변수들의 이름을 제공하는 문자열, 이터러블(iterable), 문자열의 시퀀스가 대입될 수 있습니다. __slots__ 은 선언된 변수들을 위한 공간을 예약하고, 간 인스턴스마다 __dict__ 와 __weakref__ 가 만들어지는 것을 막습니다.

3.3.2.4.1. slots 사용에 관한 노트¶

__slots__ 가 없는 클래스를 계승할 때, 인스턴스의 __dict__ 와 __weakref__ 어트리뷰트는 항상 제공됩니다.
__dict__ 변수가 없으므로 인스턴스는 __slots__ 정의에 나열되지 않은 새 변수를 대입할 수 없습니다. 나열되지 않은 변수명으로 대입하려고 하면 AttributeError 를 일으킵니다. 만약 동적으로 새 변수를 대입하는 것이 필요하다면, __slots__ 선언의 문자열 시퀀스에 '__dict__' 를 추가합니다.
인스턴스마다 __weakref__ 변수가 없으므로, __slots__ 를 정의하는 클래스는 인스턴스에 대한 약한 참조(weak reference)를 지원하지 않습니다. 만약 약한 참조 지원이 필요하다면, __slots__ 선언의 문자열 시퀀스에 '__weakref__' 를 추가합니다.

__slots__ 는 각 변수 이름마다 디스크립터를 만드는 방식으로 클래스 수준에서 구현됩니다(디스크립터 구현하기). 결과적으로, 클래스 어트리뷰트는 __slots__ 로 정의된 인스턴스 변수들을 위한 기본값을 제공할 목적으로 사용될 수 없습니다. 클래스 어트리뷰트는 디스크립터 대입을 무효로 합니다.

flowdas

클래스 정의에서 __slots__ 로 정의된 인스턴스 변수와 같은 이름의 클래스 어트리뷰트를 제공하면 예외를 일으킵니다. 하지만 클래스 어트리뷰트는 클래스 정의 밖에서도 제공할 수 있는데, 이 때 디스크립터가 제거되게 됩니다. 예를 들어:

>>> class X:
...     __slots__ = ('value',)
...     def __init__(self, value=None):
...         if value:
...             self.value = value
...
>>> x = X()
>>> x.value # 선언은 되었으나, self.value 에 아직 값이 대입되지 않았습니다.
Traceback (most recent call last):
    ...
AttributeError: value
>>> X.value # 클래스 어트리뷰트는 디스크립터입니다.
<member 'value' of 'X' objects>
>>> x.value = 2 # 값을 대입할 수는 있습니다.
>>> x.value # 이제 예외가 발생하지 않습니다.
2
>>> X.value = 1 # 기본 값으로 사용되도록 클래스 어트리뷰트를 설정하려고 하지만, 결과적으로 디스크립터를 제거하게됩니다.
>>> X.value
1
>>> x.value # 디스크립터가 제거되어, 아까 설정한 값도 읽을 수 없게됩니다.
1
>>> x.value = 2 # 값을 다시 대입할 수도 없게됩니다.
Traceback (most recent call last):
    ...
AttributeError: 'X' object attribute 'value' is read-only

__slots__ 선언으로 인한 효과는 그것이 정의된 클래스로 한정되지 않습니다. 부모가 선언한 __slots__ 은 자식 클래스에 제공됩니다. 하지만, 자식 서브 클래스가 자신의 __slots__ (새로 추가되는 변수들만 포함해야 합니다) 을 정의하지 않는다면 __dict__ 와 __weakref__ 를 갖게 됩니다.
클래스가 베이스 클래스의 __slots__ 에 정의된 이름과 같은 이름의 변수를 __slots__ 에 선언한다면, 베이스 클래스가 정의한 변수는 액세스할 수 없는 상태가 됩니다(베이스 클래스로부터 디스크립터를 직접 조회하는 경우는 예외다). 이것은 프로그램을 정의되지 않은 상태로 보내게 됩니다. 미래에는, 이를 방지하기 위한 검사가 추가될 것입니다.
int, bytes, tuple과 같은 "가변 길이(valiable-length)" 의 내장형들을 계승하는 클래스에서는 오직 빈 __slots__ 만 지원됩니다.
__slots__ 에는 문자열 이외의 이터러블을 대입할 수 있습니다. 매핑도 역시 사용할 수 있습니다. 하지만, 미래에, 각 키에 대응하는 값들의 의미가 부여될 수 있습니다.
두 클래스가 같은 __slots__ 을 갖는 경우만 __class__ 대입이 동작합니다.
슬롯을 사용하는 여러 부모 클래스들을 다중 상속할 수 있지만, 오직 하나의 부모만 슬롯으로 만들어진 어트리뷰트를 가질 수 있습니다 (다른 베이스들은 빈 슬롯을 가져야만 합니다) - 이를 어기면 TypeError 를 일으킵니다.
이터레이터가 __slots__에 사용되면 각 이터레이터의 값에 대해 디스크립터가 만들어집니다. 그러나, __slots__ 어트리뷰트는 빈 이터레이터가 됩니다.

3.3.3. 클래스 생성 커스터마이제이션¶

클래스가 다른 클래스를 상속할 때, 그 클래스의 __init_subclass__ 가 호출됩니다. 이 방법으로, 서브 클래스의 동작을 변경하는 클래스를 쓰는 것이 가능합니다. 이런 용도는 클래스 데코레이터와도 밀접히 관련되어 있습니다. 하지만 클래스 데코레이터는 그들을 사용하는 특정한 클래스에만 작용하지만, __init_subclass__ 단독으로 그 메서드를 정의하는 클래스의 미래 서브 클래스 모두에게 작용합니다.

classmethod object.__init_subclass__(cls)¶

이 메서드는 포함하는 클래스의 서브 클래스가 만들어질 때마다 호출됩니다. cls 는 새 서브 클래스입니다. 만약 일반적인 인스턴스 메서드로 정의되면, 이 메서드는 묵시적으로 클래스 메서드로 변경됩니다.

새 클래스에 주어진 키워드 인자들은 부모 클래스의 __init_subclass__ 로 전달됩니다. __init_subclass__ 를 사용하는 다른 클래스들과의 호환성을 위해, 필요한 키워드 인자들을 꺼낸 후에 다른 것들을 베이스 클래스로 전달해야 합니다. 이런 식입니다:

class Philosopher:
    def __init_subclass__(cls, /, default_name, **kwargs):
        super().__init_subclass__(**kwargs)
        cls.default_name = default_name

class AustralianPhilosopher(Philosopher, default_name="Bruce"):
    pass

기본 구현 object.__init_subclass__ 는 아무 일도 하지 않지만, 인자가 포함되어 호출되면 예외를 발생시킵니다.

참고

메타 클래스 힌트 metaclass 는 나머지 형 절차에 의해 소비되고, __init_subclass__ 로 전달되지 않습니다. 실제 메타 클래스 (명시적인 힌트 대신에) 는 type(cls) 로 액세스할 수 있습니다.

버전 3.6에 추가.

3.3.3.1. 메타 클래스¶

기본적으로, 클래스는 type() 을 사용해서 만들어집니다. 클래스의 바디는 새 이름 공간에서 실행되고, 클래스 이름은 type(name, bases, namespace) 의 결과에 지역적으로 연결됩니다.

클래스를 만드는 과정은 클래스 정의 줄에 metaclass 키워드 인자를 전달하거나, 그런 인자를 포함한 이미 존재하는 클래스를 계승함으로써 커스터마이즈될 수 있습니다. 다음 예에서, MyClass 와 MySubclass 는 모두 Meta 의 인스턴스입니다.

class Meta(type):
    pass

class MyClass(metaclass=Meta):
    pass

class MySubclass(MyClass):
    pass

클래스 정의에서 지정된 다른 키워드 인자들은 아래에서 설명되는 모든 메타 클래스 연산들로 전달됩니다.

클래스 정의가 실행될 때, 다음과 같은 단계가 수행됩니다.:

MRO 항목이 결정됩니다;
적절한 메타 클래스가 결정됩니다;
클래스 이름 공간이 준비됩니다;
클래스 바디가 실행됩니다;
클래스 객체가 만들어집니다.

3.3.3.2. MRO 항목 결정하기¶

클래스 정의에 나타나는 베이스 클래스가 type 의 인스턴스가 아닌 경우, 거기에서 __mro_entries__ 메서드를 검색합니다. 발견되면, 원래의 베이스 튜플로 호출됩니다. 이 메서드는 이 베이스 대신에 사용될 클래스의 튜플을 돌려줘야 합니다. 튜플은 비어있을 수 있습니다. 이 경우 원래 베이스는 무시됩니다.

PEP 560 - typing 모듈과 제네릭 형에 대한 코어 지원

3.3.3.3. 적절한 메타 클래스 선택하기¶

클래스 정의의 적절한 메타 클래스는 다음과 같이 결정됩니다:

베이스와 명시적인 메타 클래스를 주지 않는 경우 type() 이 사용됩니다;
명시적인 메타 클래스가 지정되고, 그것이 type() 의 인스턴스가 아니면, 그것을 메타 클래스로 사용합니다;
type() 의 인스턴스가 명시적인 메타 클래스로 주어지거나, 베이스가 정의되었으면, 가장 많이 파생된 메타 클래스가 사용됩니다.

가장 많이 파생된 메타 클래스는 명시적으로 지정된 메타 클래스(있다면)와 지정된 모든 베이스 클래스들의 메타 클래스들(즉, type(cls)) 중에서 선택됩니다. 가장 많이 파생된 메타 클래스는 이들 모두 의 서브 타입(subtype)입니다. 만약 어느 것도 이 조건을 만족하지 못한다면, 클래스 정의는 TypeError 를 발생시키며 실패합니다.

3.3.3.4. 클래스 이름 공간 준비하기¶

일단 적절한 메타 클래스가 식별되면, 클래스 이름 공간이 준비됩니다. 만약 메타 클래스가 __prepare__ 어트리뷰트를 가지면, namespace = metaclass.__prepare__(name, bases, **kwds) 같은 식으로 호출됩니다(추가적인 키워드 인자가 있다면 클래스 정의에서 온 것입니다). __prepare__ 메서드는 classmethod()로 구현되어야 합니다. __prepare__에 의해 반환된 이름 공간은 __new__에 전달되지만, 최종 클래스 객체가 만들어질 때 이름 공간이 새로운 dict에 복사됩니다.

만약 메타 클래스에 __prepare__ 어트리뷰트가 없다면, 클래스 이름 공간은 빈 순서 있는 매핑으로 초기화됩니다.

PEP 3115 - 파이썬 3000 에서의 메타 클래스: __prepare__ 이름 공간 훅을 도입했습니다

3.3.3.5. 클래스 바디 실행하기¶

클래스 바디는 (대략) exec(body, globals(), namespace) 과같이 실행됩니다. 일반적인 exec() 호출과 주된 차이점은 클래스 정의가 함수 내부에서 이루어질 때 어휘 스코핑(lexical scoping) 이 클래스 바디(모든 메서드들을 포함해서)로 하여금 현재와 외부 스코프에 있는 이름들을 참조하도록 허락한다는 것입니다.

하지만, 클래스 정의가 함수 내부에서 이루어질 때조차도, 클래스 내부에서 정의된 메서드들은 클래스 스코프에서 정의된 이름들을 볼 수 없습니다. 클래스 변수는 인스턴스나 클래스 메서드의 첫 번째 매개변수를 통해 액세스하거나 다음 섹션에서 설명하는 묵시적으로 어휘 스코핑된 __class__ 참조를 통해야 합니다.

flowdas

메서드에서 클래스 어트리뷰트를 직접 참조할 수 없다는 뜻입니다. 하지만 self, cls, __class__ 를 통하는 것 외에도, 클래스 객체에 대한 직접적인 참조를 통해 접근할 수 있습니다. 예를 들어:

class X:
    value = 'X'

    def f(self):
        print('type(self) is', type(self).value)
        print('__class__ is', __class__.value)
        print('X is', X.value)

    @classmethod
    def g(cls):
        print('cls is', cls.value)
        print('__class__ is', __class__.value)
        print('X is', X.value)

    @staticmethod
    def h():
        print('__class__ is', __class__.value)
        print('X is', X.value)

클래스 X 에 대한 직접적인 참조는, 클래스 정의가 함수 내부에서 이루어져도 가능한데, 메서드가 함수의 자유 변수들을 볼 수 있다는 규칙 때문입니다. __class__ 의 주 용도는, super() 에 인자를 주지 않을 경우(즉 super() 라고 쓸 경우), 현재 메서드가 정의된 클래스를 찾는 것입니다. 이 때문에 __class__ 는 type(self) 나 cls 보다는 X 를 사용할 때 처럼 동작합니다. 가령:

>>> class Y(X):
...     value = 'Y'
...
>>> Y().f()
type(self) is Y
__class__ is X
X is X
>>> Y.g()
cls is Y
__class__ is X
X is X
>>> Y.h()
__class__ is X
X is X

3.3.3.6. 클래스 객체 만들기¶

일단 클래스 이름 공간이 클래스 바디를 실행함으로써 채워지면, 클래스 객체가 metaclass(name, bases, namespace, **kwds) 을 통해 만들어집니다(여기에서 전달되는 추가적인 키워드 인자들은 __prepare__ 에 전달된 것들과 같습니다).

이 클래스 객체는 super() 에 인자를 주지 않는 경우 참조되는 것입니다. __class__ 는 클래스 바디의 메서드들 중 어느 하나라도 __class__ 나 super 를 참조할 경우 컴파일러에 의해 만들어지는 묵시적인 클로저(closure) 참조입니다. 이것은 인자 없는 형태의 super() 가 어휘 스코핑 기반으로 현재 정의되고 있는 클래스를 올바르게 찾을 수 있도록 합니다. 반면에 현재의 호출에 사용된 클래스나 인스턴스는 메서드로 전달된 첫 번째 인자에 기초해서 식별됩니다.

CPython implementation detail: CPython 3.6 이상에서, __class__ 셀(cell)은 클래스 이름 공간의 __classcell__ 엔트리로 메타 클래스에 전달됩니다. 만약 존재한다면, 이것은 클래스가 올바르게 초기화되기 위해 type.__new__ 호출까지 거슬러서 전파되어야 합니다. 이렇게 하지 못하면 파이썬 3.8 에서는 RuntimeError로 이어질 것입니다.

기본 메타 클래스 type 을 사용할 때나 다른 메타 클래스가 결국 type.__new__ 를 호출할 때, 클래스 객체를 만든 후에, 다음과 같은 추가의 커스터마이제이션 단계가 실행됩니다:

첫째로, type.__new__ 는 __set_name__() 을 정의하는 클래스 이름 공간의 모든 디스크립터들을 수집합니다;
둘째로, 이렇게 수집된 모든 __set_name__ 을 호출하는데, 정의되고 있는 클래스와 디스크립터에 주어진 이름을 인자로 전달합니다;
마지막으로, 메서드 결정 순서에 따라 가장 가까운 부모에 대해 __init_subclass__() 훅이 호출됩니다.

클래스 객체가 만들어진 후에, 클래스 정의에 포함된 클래스 데코레이터들에게 (있다면) 클래스를 전달하고, 그 결과를 클래스가 정의되는 지역 이름 공간에 연결합니다.

type.__new__ 로 새 클래스가 만들어질 때, 이름 공간 매개변수로 제공되는 객체는 새로 만든 순서 있는 매핑으로 복사되고, 원래의 객체는 버립니다. 새 사본은 읽기 전용 프락시(read-only proxy)로 둘러싸이는데, 이것이 클래스 객체의 __dict__ 어트리뷰트가 됩니다.

PEP 3135 - 새 super: 묵시적인 __class__ 클로저 참조를 설명합니다

3.3.3.7. 메타 클래스의 용도¶

메타 클래스의 잠재적인 용도에는 한계가 없습니다. 탐색 된 몇 가지 아이디어들에는 enum, 로깅, 인터페이스 검사, 자동화된 위임(automatic delegation), 자동화된 프로퍼티(properety) 생성, 프락시(proxy), 프레임웍(framework), 자동화된 자원 로킹/동기화(automatic resource locking/synchronization) 등이 있습니다.

3.3.4. 인스턴스 및 서브 클래스 검사 커스터마이제이션¶

다음 메서드들은 isinstance() 와 issubclass() 내장 함수들의 기본 동작을 재정의하는 데 사용됩니다.

특히, 메타 클래스 abc.ABCMeta 는 추상 베이스 클래스(Abstract Base Class, ABC)를 다른 ABC를 포함한 임의의 클래스나 형(내장형을 포함합니다)에 "가상 베이스 클래스(virtual base class)"로 추가할 수 있게 하려고 이 메서드들을 구현합니다.

class.__instancecheck__(self, instance)¶: instance 가 (직접적이거나 간접적으로) class 의 인스턴스로 취급될 수 있으면 참을 돌려줍니다. 만약 정의되면, isinstance(instance, class) 를 구현하기 위해 호출됩니다.

class.__subclasscheck__(self, subclass)¶: subclass 가 (직접적이거나 간접적으로) class 의 서브 클래스로 취급될 수 있으면 참을 돌려줍니다. 만약 정의되면, issubclass(subclass, class) 를 구현하기 위해 호출됩니다.

이 메서드들은 클래스의 형(메타 클래스)에서 조회된다는 것에 주의해야 합니다. 실제 클래스에서 클래스 메서드로 정의될 수 없습니다. 이것은 인스턴스에 대해 호출되는 특수 메서드들의 조회와 일관성 있습니다. 이 경우 인스턴스는 클래스 자체다.

PEP 3119 - 추상 베이스 클래스의 도입: __instancecheck__() 와 __subclasscheck__() 를 통해 isinstance() 와 issubclass() 의 동작을 커스터마이징하는 데 필요한 규약을 포함하는데, 이 기능의 동기는 언어에 추상 베이스 클래스 (abc 모듈을 보십시오)를 추가하고자 하는 데 있습니다.

3.3.5. 제네릭 형 흉내 내기¶

특수 메서드를 정의함으로써 PEP 484에서 지정된 제네릭 클래스 문법(예를 들면 List[int])을 구현할 수 있습니다:

classmethod object.__class_getitem__(cls, key)¶: key 에 있는 형 인자에 의한 제네릭 클래스의 특수화를 나타내는 객체를 돌려줍니다.

이 메서드는 클래스 개체 자체에서 조회되며, 클래스 바디에 정의된 경우, 이 메서드는 묵시적으로 클래스 메서드입니다. 이 메커니즘은 주로 정적 형 힌트와 함께 사용하기 위해 예약되어 있습니다. 다른 용도는 권장하지 않습니다.

PEP 560 - typing 모듈과 제네릭 형에 대한 코어 지원

3.3.6. 콜러블 객체 흉내 내기¶

object.__call__(self[, args...])¶: 인스턴스가 함수처럼 "호출될" 때 호출됩니다; 이 메서드가 정의되면, x(arg1, arg2, ...) 는 대략 type(x).__call__(x, arg1, ...)로 번역됩니다.

3.3.7. 컨테이너형 흉내 내기¶

컨테이너 객체를 구현하기 위해 다음과 같은 메서드들을 정의할 수 있습니다. 컨테이너는 보통 시퀀스(리스트와 튜플 같은)나 매핑(딕셔너리 같은)이지만, 다른 컨테이너들 역시 표현할 수 있습니다. 첫 번째 메서드 집합은 시퀀스나 매핑을 흉내 내는 데 사용됩니다; 차이점은, 시퀀스의 경우 허락되는 키는 N 이 시퀀스의 길이일 때 0 <= k < N 를 만족하는 정수 k 와 항목들의 범위를 정의하는 슬라이스 객체만 허락된다는 것입니다. 파이썬의 표준 딕셔너리 객체와 비슷하게 동작하도록, 매핑에 메서드 keys(), values(), items(), get(), clear(), setdefault(), pop(), popitem(), copy(), update() 를 제공하는 것이 좋습니다. collections.abc 모듈은 MutableMapping 추상 베이스 클래스를 제공하는데, 기본 집합 __getitem__(), __setitem__(), __delitem__(), keys() 로 부터 이들 메서드들을 만드는 데 도움을 줍니다. 파이썬의 표준 리스트 객체처럼, 가변 시퀀스는 메서드 append(), count(), index(), extend(), insert(), pop(), remove(), reverse(), sort() 를 제공해야 합니다. 마지막으로 시퀀스 형은 아래에서 설명하는 메서드 __add__(), __radd__(), __iadd__(), __mul__(), __rmul__(), __imul__() 를 정의해서 더하기(이어붙이기를 뜻합니다)와 곱하기(반복을 뜻합니다)를 구현해야 합니다. 다른 숫자 연산자들은 정의하지 말아야 합니다. in 연산자의 효과적인 사용을 허락하기 위해, 매핑과 시퀀스 모두 __contains__() 메서드를 구현하도록 권장합니다. 매핑의 경우, in 은 매핑의 키를 검색해야 합니다; 시퀀스의 경우, 값들을 검색해야 합니다. 컨테이너의 효율적인 이터레이션을 허락하기 위해, 매핑과 시퀀스 모두 __iter__() 메서드를 구현하는 것 또한 권장합니다; 매핑의 경우, __iter__() 는 객체의 키를 이터레이트 해야 합니다; 시퀀스의 경우, 값들을 이터레이트해야 합니다.

object.__len__(self)¶: 내장함수 len() 를 구현하기 위해 호출됩니다. 객체의 길이를 돌려줘야 하는데, >= 0인 정수입니다. 또한 __bool__() 메서드를 정의하지 않은 객체의 __len__() 이 0을 돌려주면 논리 문맥에서 거짓으로 취급됩니다.

CPython implementation detail: CPython 에서, 길이는 최대 sys.maxsize 일 것이 요구됩니다. 만약 길이가 sys.maxsize 보다 크면, 어떤 기능들 (len() 과 같은)은 OverflowError 를 일으킬 수 있습니다. 참 거짓 검사에서 OverflowError 가 일어나는 것을 막기 위해, 객체는 __bool__() 를 정의해야 합니다.

object.__length_hint__(self)¶: operator.length_hint() 를 구현하기 위해 호출됩니다. 객체의 추정된 길이를 돌려줘야 합니다(실제 길이보다 크거나 작을 수 있습니다). 길이는 >= 0인 정수여야 합니다. 반환 값은 NotImplemented 일 수도 있으며, __length_hint__ 메서드가 아예 존재하지 않는 것처럼 처리됩니다. 이 메서드는 순수하게 최적화를 위한 것이고 결코 올바름이 요구되지는 않습니다.

버전 3.4에 추가.

참고

슬라이싱은 전적으로 다음에 나오는 세 메서드들에의해 수행됩니다

a[1:2] = b

과 같은 호출은

a[slice(1, 2, None)] = b

로 번역되고, 다른 형태도 마찬가지입니다. 빠진 슬라이스 항목은 항상 None 으로 채워집니다.

flowdas

"다음에 나오는 세 메서드들" 은 __getitem__(), __setitem__(), __delitem__() 를 의미합니다.

object.__getitem__(self, key)¶: self[key] 의 값을 구하기 위해 호출됩니다. 시퀀스형의 경우, 정수와 슬라이스 객체만 키로 허용됩니다. 음수 인덱스(만약 클래스가 시퀀스 형을 흉내 내길 원한다면)의 특별한 해석은 __getitem__() 메서드에 달려있음에 주의해야 합니다. 만약 key 가 적절하지 않은 형인 경우, TypeError 가 발생할 수 있습니다; 만약 시퀀스의 인덱스 범위를 벗어나면(음수에 대한 특별한 해석 후에), IndexError 를 일으켜야 합니다. 매핑 형의 경우, key 가 (컨테이너에) 없으면, KeyError 를 일으켜야 합니다.

참고

for 루프는 시퀀스의 끝을 올바로 감지하기 위해, 잘못된 인덱스에 대해 IndexError 가 일어날 것으로 기대하고 있습니다.

flowdas

for 루프는, 객체가 __iter__() 를 정의하지 않을 경우, 0 부터 시작해서 하나씩 증가하는 정수를 사용해서 차례대로 __getitem__() 을 호출합니다. IndexError 가 발생할 때까지 이 과정을 계속 진행합니다. 이 때 IndexError 는 for 루프의 종료 신호로 사용될 뿐, 루프 바깥으로 확산되지 않습니다.

object.__setitem__(self, key, value)¶: self[key] 로의 대입을 구현하기 위해 호출됩니다. __getitem__() 과 같은 주의가 필요합니다. 매핑의 경우에는, 객체가 키에 대해 값의 변경이나 새 키의 추가를 허락할 경우, 시퀀스의 경우는 항목이 교체될 수 있을 때만 구현되어야 합니다. 잘못된 key 값의 경우는 __getitem__() 에서와 같은 예외를 일으켜야 합니다.

object.__delitem__(self, key)¶: self[key] 의 삭제를 구현하기 위해 호출됩니다. __getitem__() 과 같은 주의가 필요합니다. 매핑의 경우에는, 객체가 키의 삭제를 허락할 경우, 시퀀스의 경우는 항목이 시퀀스로부터 제거될 수 있을 때만 구현되어야 합니다. 잘못된 key 값의 경우는 __getitem__() 에서와 같은 예외를 일으켜야 합니다.

object.__missing__(self, key)¶: dict.__getitem__() 이 dict 서브 클래스에서 키가 딕셔너리에 없으면 self[key] 를 구현하기 위해 호출합니다.

flowdas

dict 가 이 메서드를 미리 정의하고 있지는 않습니다. 서브 클래스가 정의한다면 호출한다는 뜻입니다.

object.__iter__(self)¶

컨테이너의 이터레이터가 필요할 때 이 메서드가 호출됩니다. 이 메서드는 컨테이너에 포함된 모든 객체를 이터레이트할 수 있는 이터레이터 객체를 돌려줘야 합니다. 매핑의 경우, 컨테이너의 키를 이터레이트해야 합니다.

이터레이터 객체 역시 이 메서드를 구현할 필요가 있습니다; 자기 자신을 돌려줘야 합니다. 이터레이터 객체에 대한 추가의 정보는 이터레이터 형 에 있습니다.

object.__reversed__(self)¶

reversed() 내장 함수가 역 이터레이션(reverse iteration)을 구현하기 위해 (있다면) 호출합니다. 컨테이너에 있는 객체들을 역 순으로 탐색하는 새 이터레이터 객체를 돌려줘야 합니다.

__reversed__() 메서드가 제공되지 않으면, reversed() 내장함수는 시퀀스 프로토콜(__len__() 과 __getitem__())을 대안으로 사용합니다. 시퀀스 프로토콜을 지원하는 객체들은 reversed() 가 제공하는 것보다 더 효율적인 구현을 제공할 수 있을 때만 __reversed__() 를 제공해야 합니다.

멤버십 검사 연산자들(in 과 not in) 은 보통 컨테이너에 대한 이터레이션으로 구현됩니다. 하지만, 컨테이너 객체는 더 효율적인 구현을 다음과 같은 특수 메서드를 통해 제공할 수 있습니다. 이 경우 객체는 이터러블일 필요도 없습니다.

object.__contains__(self, item)¶

멤버십 검사 연산자를 구현하기 위해 호출됩니다. item 이 self 에 있으면 참을, 그렇지 않으면 거짓을 돌려줘야 합니다. 매핑 객체의 경우, 키-값 쌍이 아니라 매핑의 키가 고려되어야 합니다.

__contains__() 를 정의하지 않는 객체의 경우, 멤버십 검사는 먼저 __iter__() 를 통한 이터레이션을 시도한 후, __getitem__() 을 통한 낡은 시퀀스 이터레이션 프로토콜을 시도합니다. 언어 레퍼런스의 이 절을 참고하십시오.

3.3.8. 숫자 형 흉내 내기¶

숫자 형을 흉내 내기 위해 다음과 같은 메서드들을 정의할 수 있습니다. 구현되는 특별한 종류의 숫자에 의해 지원되지 않는 연산들(예를 들어, 정수가 아닌 숫자들에 대한 비트 연산들)에 대응하는 메서드들을 정의되지 않은 채로 남겨두어야 합니다.

object.__add__(self, other)¶

object.__sub__(self, other)¶

object.__mul__(self, other)¶

object.__matmul__(self, other)¶

object.__truediv__(self, other)¶

object.__floordiv__(self, other)¶

object.__mod__(self, other)¶

object.__divmod__(self, other)¶

object.__pow__(self, other[, modulo])¶

object.__lshift__(self, other)¶

object.__rshift__(self, other)¶

object.__and__(self, other)¶

object.__xor__(self, other)¶

object.__or__(self, other)¶

이 메서드들은 이항 산술 연산들(+, -, *, @, /, //, %, divmod(), pow(), **, <<, >>, &, ^, |)을 구현하기 위해 호출됩니다. 예를 들어, x 가 __add__() 메서드를 가진 클래스의 인스턴스일 때, 표현식 x + y 의 값을 구하기 위해, x.__add__(y) 가 호출됩니다. __divmod__() 메서드는 __floordiv__() 와 __mod__() 를 사용하는 것과 동등해야 합니다; __truediv__() 와 연관되지 않아야 합니다; 내장 pow() 함수의 삼 항 버전이 지원되기 위해서는, __pow__() 메서드가 생략할 수 있는 세 번째 인자를 받도록 정의되어야 함에 주의해야 합니다.

만약 이 메서드들 중 하나가 제공된 인자에 대해 연산을 지원하지 않으면, NotImplemented 를 돌려줘야 합니다.

object.__radd__(self, other)¶

object.__rsub__(self, other)¶

object.__rmul__(self, other)¶

object.__rmatmul__(self, other)¶

object.__rtruediv__(self, other)¶

object.__rfloordiv__(self, other)¶

object.__rmod__(self, other)¶

object.__rdivmod__(self, other)¶

object.__rpow__(self, other[, modulo])¶

object.__rlshift__(self, other)¶

object.__rrshift__(self, other)¶

object.__rand__(self, other)¶

object.__rxor__(self, other)¶

object.__ror__(self, other)¶

이 메서드들은 뒤집힌 피연산자들에 대해 이항 산술 연산들(+, -, *, @, /, //, %, divmod(), pow(), **, <<, >>, &, ^, |)을 구현하기 위해 호출됩니다. 이 함수들은 왼쪽의 피연산자가 해당 연산을 지원하지 않고 3, 피연산자들이 서로 다른 형일 때만 호출됩니다. 4 예를 들어, 표현식 x - y 의 값을 구하려고 할 때, y 가 __rsub__() 를 갖는 클래스의 인스턴스이고, x.__sub__(y) 가 NotImplemented 를 돌려주면 y.__rsub__(x) 가 호출됩니다.

삼 항 pow() 는 __rpow__() 를 호출하려고 시도하지 않음에 주의해야 합니다 (그렇게 하려면 코어션 규칙이 너무 복잡해집니다).

참고

만약 오른쪽 피연산자의 형이 왼쪽 피연산자의 형의 서브 클래스이고, 그 서브 클래스가 연산의 뒤집힌 메서드의 다른 구현을 제공하면, 이 메서드가 왼쪽 연산자의 뒤집히지 않은 메서드보다 먼저 호출됩니다. 이 동작은 서브 클래스가 조상들의 연산을 재정의할 수 있도록 합니다.

object.__iadd__(self, other)¶

object.__isub__(self, other)¶

object.__imul__(self, other)¶

object.__imatmul__(self, other)¶

object.__itruediv__(self, other)¶

object.__ifloordiv__(self, other)¶

object.__imod__(self, other)¶

object.__ipow__(self, other[, modulo])¶

object.__ilshift__(self, other)¶

object.__irshift__(self, other)¶

object.__iand__(self, other)¶

object.__ixor__(self, other)¶

object.__ior__(self, other)¶

이 메서드들은 증분 산술 대입(+=, -=, *=, @=, /=, //=, %=, **=, <<=, >>=, &=, ^=, |=)을 구현하기 위해 호출됩니다. 이 메서드는 연산을 제자리에서(self 를 수정해서) 하도록 시도해야 하고, 결과(반드시 그래야 하는 것은 아니지만 self 일 수 있습니다)를 돌려줘야 합니다. 만약 특정 메서드가 정의되지 않으면, 중분 대입은 일반적인 메서드들을 대신 사용합니다. 예를 들어, x 가 __iadd__() 메서드를 갖는 클래스의 인스턴스면, x += y 는 x = x.__iadd__(y) 와 동등합니다. 그렇지 않으면, x + y 의 값을 구할 때처럼, x.__add__(y) 와 y.__radd__(x) 가 고려됩니다. 어떤 상황에서, 증분 대입은 예상치 못한 에러로 이어질 수 있습니다. (덧셈은 작동하는데, 왜 a_tuple[i] += ['item']이 예외를 일으킵니까? 를 보십시오). 하지만 이 동작은 사실 데이터 모델의 일부입니다.

flowdas

덧셈은 작동하는데, 왜 a_tuple[i] += ['item']이 예외를 일으킵니까? 는 이런 상황을 예시하고 있습니다:

>>> a_tuple = (['foo'], 'bar')
>>> a_tuple[0] += ['item']
Traceback (most recent call last):
  ...
TypeError: 'tuple' object does not support item assignment

이 에러는 a_tuple[0] += ['item'] 을 동등한 표현인 a_tuple[0] = a_tuple[0].__iadd__(['item']) 로 풀어 써 보면 당연한 결과입니다. 대입문의 우변을 계산하는데는 문제가 없지만, 튜플의 항목에 대입하려는 순간 에러가 발생합니다. 이 사실 자체는 튜플이 불변객체이기 때문에 이상할 것이 없습니다.

하지만 진짜 문제는 증분 대입문이 원자적이지 않다는 사실입니다. 원자적이지 않다는 것은 오류가 발생해서 실패했음에도 불구하고, 실행 전과 비교할 때 뭔가 달라졌다는 뜻입니다. 우변의 표현은 성공하는데, 이 때 실행된 것은 list.__iadd__() 입니다. 이 메서드는 자기 자신을 변경한 후에 self 를 돌려줍니다. 그 결과, 비록 튜플을 변경하려는 시도는 실패하지만, 이미 튜플안에 들어있던 리스트는 변경된 상태로 남게 됩니다:

>>> a_tuple
(['foo', 'item'], 'bar')

참고

**= 디스패치 메커니즘의 버그로 인해, __ipow__()를 정의하지만 NotImplemented를 반환하는 클래스는 x.__pow__(y)와 y.__rpow__(x)로 폴백 되지 않습니다. 이 버그는 파이썬 3.10에서 수정되었습니다.

object.__neg__(self)¶
object.__pos__(self)¶
object.__abs__(self)¶
object.__invert__(self)¶: 일 항 산술 연산(-, +, abs(), ~)을 구현하기 위해 호출됩니다.

object.__complex__(self)¶
object.__int__(self)¶
object.__float__(self)¶: 내장 함수 complex(), int(), float()를 구현하기 위해 호출됩니다. 적절한 형의 값을 돌려줘야 합니다.

object.__index__(self)¶

operator.index() 를 구현하기 위해 호출되고, 파이썬이 숫자 객체를 정수 객체로 손실 없이 변환해야 할 때(슬라이싱이나 내장 bin(), hex(), oct() 함수들에서와같이)마다 호출됩니다. 이 메서드의 존재는 숫자 객체가 정수 형임을 가리킵니다. 반드시 정수를 돌려줘야 합니다.

flowdas

가령 x[y:] 라는 표현이 있을 때 y 가 정수형이 아니면 x[y.__index__():] 와 같은 표현으로 변환된다는 뜻입니다.

__int__(), __float__() 및 __complex__()가 정의되어 있지 않으면, 해당 내장 함수 int(), float() 및 complex()는 __index__()를 사용합니다.

object.__round__(self[, ndigits])¶

object.__trunc__(self)¶

object.__floor__(self)¶

object.__ceil__(self)¶

내장 함수 round()와 math 함수 trunc(), floor(), ceil() 을 구현하기 위해 호출됩니다. ndigits 가 __round__() 로 전달되지 않는 한, 이 메서드들은 모두 Integral (보통 int) 로 잘린 객체의 값을 돌려줘야 합니다.

__int__() 가 정의되어 있지 않으면, 내장 함수 int() 는 __trunc__() 를 사용합니다.

3.3.9. with 문 컨텍스트 관리자¶

컨텍스트 관리자 (context manager) 는 with 문을 실행할 때 자리 잡는 실행 컨텍스트(context)를 정의하는 객체입니다. 코드 블록의 실행을 위해, 컨텍스트 관리자는 원하는 실행시간 컨텍스트로의 진입과 탈출을 처리합니다. 컨텍스트 관리자는 보통 with 문(with 문 섹션에서 설명합니다)으로 시작되지만, 그들의 메서드를 호출해서 직접 사용할 수도 있습니다.

컨텍스트 관리자의 전형적인 용도에는 다양한 종류의 전역 상태(global state)를 보관하고 복구하는 것, 자원을 로킹(locking)하고 언로킹(unlocking)하는 것, 열린 파일을 닫는 것 등이 있습니다.

컨텍스트 관리자에 대한 더 자세한 정보는 컨텍스트 관리자 형 에 나옵니다.

object.__enter__(self)¶: 이 객체와 연관된 실행시간 컨텍스트에 진입합니다. with 문은 as 절로 지정된 대상이 있다면, 이 메서드의 반환 값을 연결합니다.

object.__exit__(self, exc_type, exc_value, traceback)¶

이 객체와 연관된 실행시간 컨텍스트를 종료합니다. 매개변수들은 컨텍스트에서 벗어나게 만든 예외를 기술합니다. 만약 컨텍스트가 예외 없이 종료한다면, 세 인자 모두 None 이 됩니다.

만약 예외가 제공되고, 메서드가 예외를 중지시키고 싶으면 (즉 확산하는 것을 막으려면) 참(true)을 돌려줘야 합니다. 그렇지 않으면 예외는 이 메서드가 종료한 후에 계속 진행됩니다.

__exit__() 메서드가 전달된 예외를 다시 일으키지(reraise) 않도록 주의해야 합니다; 이것은 호출자(caller)의 책임입니다.

PEP 343 - "with" 문: 파이썬 with 문에 대한 규격, 배경, 예.

3.3.10. 특수 메서드 조회¶

사용자 정의 클래스의 경우, 묵시적인 특수 메서드의 호출은 객체의 인스턴스 딕셔너리가 아닌 객체의 형에 정의되어 있을 때만 올바르게 동작함이 보장됩니다. 이런 동작은 다음과 같은 코드가 예외를 일으키는 원인입니다:

>>> class C:
...     pass
...
>>> c = C()
>>> c.__len__ = lambda: 5
>>> len(c)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: object of type 'C' has no len()

이런 동작의 배경에 깔린 논리는, 모든 객체(형 객체를 포함해서)에 의해 구현되는 __hash__() 나 __repr__() 과 같은 많은 특수 메서드들과 관련이 있습니다. 만약 이 메서드들에 대한 묵시적인 조회가 일반적인 조회 프로세스를 거친다면, 형 객체 자체에 대해 호출되었을 때 실패하게 됩니다:

>>> 1 .__hash__() == hash(1)
True
>>> int.__hash__() == hash(int)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: descriptor '__hash__' of 'int' object needs an argument

flowdas

구문 분석 단계를 무사히 통과하기 위해서, 숫자 리터럴 1 과 . 사이에 공백이 삽입되었습니다. 그렇지 않으면 . 이 숫자 리터럴의 일부로 판단되어 SyntaxError 가 발생합니다.

flowdas

int.__hash__() 는 클래스 메서드가 아닌 일반 메서드입니다. 따라서 일반적인 메서드 호출 규칙을 따르고, self 에 해당하는 인자를 필요로 합니다. 이렇게 모든 객체에 공통적으로 적용되는 메서드들은, 한가지 유형을 공유해야 하기 때문에, 1 .__hash__() 에서는 일반 메서드 호출 규칙을 따르고, int.__hash__() 에서는 클래스 메서드 호출 규칙을 따르는 식으로 처리하려면, 메서드 호출 규칙이 너무 복잡해집니다. 때문에 메서드 호출 규칙은 손대지 않고 hash() 가 항상 대상 객체의 형에 정의된 __hash__() 를 사용하는 것으로 딜레마를 해결합니다. 따라서 hash(1) 은 int.__hash__() 를 사용하고, hash(int) 는 type.__hash__() 를 사용합니다. (type 은 int 형의 메타클래스입니다.)

클래스의 연결되지 않은 메서드를 호출하려는 이런 식의 잘못된 시도는 종종 '메타 클래스 혼란(metaclass confusion)' 이라고 불리고, 특수 메서드를 조회할 때 인스턴스를 우회하는 방법으로 피할 수 있습니다.

>>> type(1).__hash__(1) == hash(1)
True
>>> type(int).__hash__(int) == hash(int)
True

올바름을 추구하기 위해 인스턴스 어트리뷰트들을 우회하는 것에 더해, 묵시적인 특수 메서드 조회는 객체의 메타 클래스의 __getattribute__() 메서드 조차도 우회합니다:

>>> class Meta(type):
...     def __getattribute__(*args):
...         print("Metaclass getattribute invoked")
...         return type.__getattribute__(*args)
...
>>> class C(object, metaclass=Meta):
...     def __len__(self):
...         return 10
...     def __getattribute__(*args):
...         print("Class getattribute invoked")
...         return object.__getattribute__(*args)
...
>>> c = C()
>>> c.__len__()                 # 인스턴스를 통한 명시적 조회
Class getattribute invoked
10
>>> type(c).__len__(c)          # 형을 통한 명시적 조회
Metaclass getattribute invoked
10
>>> len(c)                      # 묵시적 조회
10

이런 식으로 __getattribute__() 절차를 우회하는 것은 특수 메서드 처리의 유연함을 일부 포기하는 대신(특수 메서드가 인터프리터에 의해 일관성 있게 호출되기 위해서는 반드시 클래스 객체에 설정되어야 합니다), 인터프리터 내부에서의 속도 최적화를 위한 상당한 기회를 제공합니다.

3.4. 코루틴(Coroutines)¶

3.4.1. 어웨이터블 객체(Awaitable Objects)¶

어웨이터블 객체는 일반적으로 __await__() 메서드를 구현합니다. async def 함수가 돌려주는 코루틴 객체는 어웨이터블입니다.

flowdas

어웨이터블 객체란 await 표현식에 사용될 수 있는 객체를 뜻합니다.

참고

types.coroutine() 이나 asyncio.coroutine() 로 데코레이션된 제너레이터가 돌려주는 제너레이터 이터레이터 객체 또한 어웨이터블이지만 __await__() 를 구현하지 않습니다.

object.__await__(self)¶: 이터레이터 를 돌려줘야 합니다. 어웨이터블 객체를 구현하기 위해 사용되어야 합니다. 예를 들어, asyncio.Future 는 await 표현식과 호환되기 위해 이 메서드를 구현합니다.

버전 3.5에 추가.

PEP 492 가 어웨이터블 객체에 대한 더 자세한 정보를 포함하고 있습니다.

3.4.2. 코루틴 객체(Coroutine Objects)¶

코루틴 객체는 어웨이터블 객체입니다. 코루틴의 실행은 __await__() 를 호출하고 그 결과를 이터레이트하는 방법으로 제어될 수 있습니다. 코루틴이 실행을 완료하고 복귀할 때, 이터레이터는 StopIteration 을 일으키고, 예외의 value 어트리뷰트가 반환 값을 갖고 있습니다. 만약 코루틴이 예외를 일으키면, 이터레이터에 의해 퍼집니다. 코루틴이 직접 잡히지 않은 StopIteration 예외를 일으키지는 말아야 합니다.

코루틴은 다음에 나열하는 메서드들 또한 갖고 있는데, 제너레이터(제너레이터-이터레이터 메서드 를 보십시오)의 것들과 닮았습니다. 하지만, 제너레이터와는 달리, 코루틴은 이터레이션을 직접 지원하지는 않습니다.

버전 3.5.2에서 변경: 코루틴을 두 번 await 하면 RuntimeError 를 일으킵니다.

coroutine.send(value)¶: 코루틴의 실행을 시작하거나 재개합니다. value 가 None 이면, __await__() 가 돌려준 이터레이터를 전진시키는 것과 같습니다. value 가 None 이 아니면, 이 메서드는 코루틴이 일시 중지되도록 한 이터레이터의 send() 메서드로 위임합니다. 결과(반환 값, StopIteration 이나 다른 예외)는 위에서 설명한 __await__() 의 반환 값을 이터레이트할 때와 같습니다.

coroutine.throw(type[, value[, traceback]])¶: 코루틴에서 지정한 예외가 발생하도록 합니다. 이 메서드는 코루틴이 일시 중지되도록 한 이터레이터의 throw() 메서드로 위임합니다(그런 메서드를 가지는 경우). 그렇지 않으면, 일시 중지지점에서 예외가 발생합니다. 결과(반환 값, StopIteration 이나 다른 예외)는 위에서 설명한 __await__() 의 반환 값을 이터레이트할 때와 같습니다. 만약 예외가 코루틴에서 잡히지 않는다면 호출자에게 되돌아 전파됩니다.

coroutine.close()¶

코루틴이 자신을 정리하고 종료하도록 만듭니다. 만약 코루틴이 일시 중지 중이면, 이 메서드는 먼저 코루틴이 일시 중지되도록 한 이터레이터의 close() 메서드로 위임합니다(그런 메서드를 가지는 경우). 그런 다음 일시 중지지점에서 GeneratorExit 를 발생시키는데, 코루틴이 즉시 자신을 정리하도록 만듭니다. 마지막으로 코루틴에 실행을 종료했다고 표시하는데, 아직 시작하지조차 않았을 때도 그렇다.

코루틴 객체가 파괴될 때는 위의 프로세스에 따라 자동으로 닫힙니다(closed).

3.4.3. 비동기 이터레이터(Asynchronous Iterators)¶

비동기 이터레이터 는 자신의 __anext__ 메서드에서 비동기 코드를 호출할 수 있습니다.

비동기 이터레이터는 async for 문에서 사용될 수 있습니다.

object.__aiter__(self)¶: 비동기 이터레이터 객체를 돌려줘야 합니다.

object.__anext__(self)¶: 이터레이터의 다음 값을 주는 어웨이터블 을 돌려줘야 합니다. 이터레이션이 끝나면 StopAsyncIteration 에러를 일으켜야 합니다.

flowdas

다음에 나오는 예에서 드러나듯이, __anext__() 를 async def 로 구현하는 경우, 코루틴이 만들어지기 때문에 항상 어웨이터블을 돌려줍니다. 이 경우, 메서드의 return 문에서 이터레이터의 다음 값을 제공하면 됩니다.

비동기 이터러블 객체의 예:

class Reader:
    async def readline(self):
        ...

    def __aiter__(self):
        return self

    async def __anext__(self):
        val = await self.readline()
        if val == b'':
            raise StopAsyncIteration
        return val

버전 3.5에 추가.

버전 3.7에서 변경: 파이썬 3.7 이전에, __aiter__ 는 비동기 이터레이터 로 결정될 어웨이터블 을 반환 할 수 있었습니다.

파이썬 3.7부터, __aiter__ 는 반드시 비동기 이터레이터 객체를 돌려줘야 합니다. 다른 것을 돌려주면 TypeError 에러가 발생합니다.

flowdas

CPython 3.5.0 과 3.5.1 에서만 이 호환성 문제가 발생하는데, 이 버전들에서는 __aiter__ 가 async def 로 정의되었었습니다.

3.4.4. 비동기 컨텍스트 관리자¶

비동기 컨텍스트 관리자(asynchronous context manager) 는 __aenter__ 와 __aexit__ 메서드에서 실행을 일시 중지할 수 있는 컨텍스트 관리자 입니다.

비동기 컨텍스트 관리자는 async with 문에서 사용될 수 있습니다.

object.__aenter__(self)¶: __enter__() 메서드와 의미상으로 유사한데, 유일한 차이점은 어웨이터블 을 돌려줘야 한다는 것입니다.

object.__aexit__(self, exc_type, exc_value, traceback)¶: __exit__() 메서드와 의미상으로 유사한데, 유일한 차이점은 어웨이터블 을 돌려줘야 한다는 것입니다.

비동기 컨텍스트 관리자 클래스의 예:

class AsyncContextManager:
    async def __aenter__(self):
        await log('entering context')

    async def __aexit__(self, exc_type, exc, tb):
        await log('exiting context')

버전 3.5에 추가.

각주

1: 어떤 제한된 조건으로, 어떤 경우에 객체의 형을 변경하는 것이 가능합니다. 하지만 잘못 다뤄지면 아주 괴상한 결과로 이어질 수 있으므로 일반적으로 좋은 생각이 아닙니다.
2: __hash__(), __iter__(), __reversed__(), __contains__() 메서드들이 이런 경우에 대한 특별한 처리를 포함하고 있습니다; 다른 것들도 여전히 TypeError 을 일으키지만, 단지 None 이 콜러블이 아니므로 그런 것뿐입니다.
3: 여기서 "지원하지 않는다" 는 클래스가 그런 메서드를 갖지 않거나, 메서드가 NotImplemented 를 돌려줌을 뜻합니다. 오른쪽 피연산자의 뒤집힌 메서드를 사용하는 대안이 시도되도록 하려면 메서드를 None 으로 설정하지 말아야 합니다 - 그렇게 하는 것은 그런 대안을 명시적으로 금지하는 반대 효과를 줍니다.
4: 피연산자들이 같은 형이면, 뒤집히지 않은 메서드(가령 __add__())가 실패하면 그 전체 연산이 지원되지 않는 것으로 간주합니다. 이것이 뒤집힌 메서드가 호출되지 않는 이유입니다.

3. 데이터 모델¶

3.1. 객체, 값, 형¶

3.2. 표준형 계층¶

3.3. 특수 메서드 이름들¶

3.3.1. 기본적인 커스터마이제이션¶

3.3.2. 어트리뷰트 액세스 커스터마이제이션¶

3.3.2.1. 모듈 어트리뷰트 액세스 커스터마이제이션¶

3.3.2.2. 디스크립터 구현하기¶

3.3.2.3. 디스크립터 호출하기¶

3.3.2.4. slots¶

3.3.2.4.1. slots 사용에 관한 노트¶

3.3.3. 클래스 생성 커스터마이제이션¶

3.3.3.1. 메타 클래스¶

3.3.3.2. MRO 항목 결정하기¶

3.3.3.3. 적절한 메타 클래스 선택하기¶

3.3.3.4. 클래스 이름 공간 준비하기¶

3.3.3.5. 클래스 바디 실행하기¶

3.3.3.6. 클래스 객체 만들기¶

3.3.3.7. 메타 클래스의 용도¶

3.3.4. 인스턴스 및 서브 클래스 검사 커스터마이제이션¶

3.3.5. 제네릭 형 흉내 내기¶

3.3.6. 콜러블 객체 흉내 내기¶

3.3.7. 컨테이너형 흉내 내기¶

3.3.8. 숫자 형 흉내 내기¶

3.3.9. with 문 컨텍스트 관리자¶

3.3.10. 특수 메서드 조회¶

3.4. 코루틴(Coroutines)¶

3.4.1. 어웨이터블 객체(Awaitable Objects)¶

3.4.2. 코루틴 객체(Coroutine Objects)¶

3.4.3. 비동기 이터레이터(Asynchronous Iterators)¶

3.4.4. 비동기 컨텍스트 관리자¶

목차

이전 항목

다음 항목

3. 데이터 모델¶

3.1. 객체, 값, 형¶

3.2. 표준형 계층¶

3.3. 특수 메서드 이름들¶

3.3.1. 기본적인 커스터마이제이션¶

3.3.2. 어트리뷰트 액세스 커스터마이제이션¶

3.3.2.1. 모듈 어트리뷰트 액세스 커스터마이제이션¶

3.3.2.2. 디스크립터 구현하기¶

3.3.2.3. 디스크립터 호출하기¶

3.3.2.4. __slots__¶

3.3.2.4.1. __slots__ 사용에 관한 노트¶

3.3.3. 클래스 생성 커스터마이제이션¶

3.3.3.1. 메타 클래스¶

3.3.3.2. MRO 항목 결정하기¶

3.3.3.3. 적절한 메타 클래스 선택하기¶

3.3.3.4. 클래스 이름 공간 준비하기¶

3.3.3.5. 클래스 바디 실행하기¶

3.3.3.6. 클래스 객체 만들기¶

3.3.3.7. 메타 클래스의 용도¶

3.3.4. 인스턴스 및 서브 클래스 검사 커스터마이제이션¶

3.3.5. 제네릭 형 흉내 내기¶

3.3.6. 콜러블 객체 흉내 내기¶

3.3.7. 컨테이너형 흉내 내기¶

3.3.8. 숫자 형 흉내 내기¶

3.3.9. with 문 컨텍스트 관리자¶

3.3.10. 특수 메서드 조회¶

3.4. 코루틴(Coroutines)¶

3.4.1. 어웨이터블 객체(Awaitable Objects)¶

3.4.2. 코루틴 객체(Coroutine Objects)¶

3.4.3. 비동기 이터레이터(Asynchronous Iterators)¶

3.4.4. 비동기 컨텍스트 관리자¶

3.3.2.4. slots¶

3.3.2.4.1. slots 사용에 관한 노트¶