역사.
Python 3.6 이전에는 속성 이름을 알아야 하는 설명자는 사용자 정의 메타클래스나 수동 클래스 데코레이터를 통해 클래스 사전을 스캔하고 이름을 주입해야 했습니다. 이 접근 방식은 장황하고 오류가 발생하기 쉬우며 복잡한 계층에서 메타클래스 충돌을 일으켰습니다. PEP 487은 Python 3.6에서 __set_name__ 프로토콜을 도입하여 인터프리터가 설명자에게 자동으로 알릴 수 있도록 하여 이러한 보일러플레이트를 제거했습니다.
문제.
설명자 인스턴스는 클래스 본체 실행 중에 생성되지만 그 순간에는 바인딩된 변수 이름이나 그 클래스에 대한 내재적 지식이 없습니다. 이 정보는 유의미한 오류 메시지를 생성하거나 ORM 시스템에 필드를 등록하거나 직렬화 스키마를 구축하는 데 필수적입니다. 외부 알림이 없으면 설명자는 익명 상태로 남아 개발자가 문자열 인수로 속성 이름을 반복하게 만들고 DRY 원칙을 위반하게 됩니다.
해결책.
type.__new__가 클래스를 구성할 때, __prepare__가 반환한 네임스페이스 매핑을 반복합니다. __set_name__ 메서드를 가진 각 값에 대해 인터프리터는 value.__set_name__(owner_class, attribute_name)를 호출합니다. 이 메서드는 생성 중인 클래스와 속성 문자열을 수신하여 설명자가 이 메타데이터를 저장할 수 있도록 합니다. 그러나 설명자가 클래스 생성 프로세스가 완료된 후 클래스 속성에 할당되면 (몽키 패칭), 타입 기계가 더 이상 활성화되지 않기 때문에 __set_name__는 자동으로 호출되지 않습니다.
class TrackedDescriptor: def __set_name__(self, owner, name): self.owner = owner self.name = name def __get__(self, instance, owner): if instance is None: return self return f"{self.owner.__name__}.{self.name}" class Model: field = TrackedDescriptor() # Model.field.name == 'field' # Model.field.owner == Model
맥락.
구성 관리 라이브러리를 개발하는 동안 환경 변수를 나타내기 위해 설명자가 필요했습니다. 값이 없거나 유효하지 않을 경우 오류는 클래스 내의 정확한 속성 이름을 지정해야 했습니다(예: Config.database_url is required), 단순한 일반 메시지가 아닙니다.
문제.
처음에 사용자는 이름을 수동으로 지정해야 했습니다: database_url = EnvVar('database_url'). 이로 인해 문자열 리터럴과 변수 이름이 분리되어 리팩토링 과정에서 버그가 발생하게 되었고, 이는 모호한 런타임 오류를 일으켰습니다.
고려한 다양한 솔루션:
메타클래스 주입. 우리는 attrs를 검사하고 각 설명자에서 attr.set_name(name)을 호출하는 ConfigMeta를 구현했습니다. 이 방법은 작동했지만 모든 사용자 클래스가 우리의 메타클래스에서 상속받아야 했으며, 이로 인해 abc.ABCMeta와 같은 자신의 메타클래스를 사용하는 다른 라이브러리와의 호환성이 깨졌습니다. 사용자들이 메타클래스에 익숙하지 않으면 인지적 오버헤드가 추가되었습니다.
클래스 데코레이터 패칭. 우리는 클래스 생성 후 cls.__dict__를 반복하고 이름을 패칭하는 @config 데코레이터를 만들었습니다. 이 방법은 메타클래스 충돌을 피했지만 선택적이었으며, 데코레이터를 잊어버리면 설명자가 깨지게 됩니다. 또한 클래스 생성 후 실행되기 때문에 설명자는 __init_subclass__ 훅에서 이름을 사용할 수 없어 반사 기능이 제한되었습니다.
__set_name__ 프로토콜. 우리는 우리의 EnvVar 설명자에 __set_name__을 추가했습니다. 이는 사용자 코드에 변경이 필요 없었고, 클래스 정의 중에 자동으로 작동했으며, 설명자가 __init_subclass__가 완료되기 전에 자신의 이름을 알 수 있게 하여 조기 검증을 가능하게 했습니다.
선택된 솔루션.
우리는 __set_name__을 채택했습니다. 이는 사용자에게 비용이 없는 추상화를 제공하며 Python의 기본 데이터 모델과 통합되었습니다. 메타클래스 충돌 문제를 완전히 제거했습니다.
결과.
API는 선언적으로 변했습니다: database_url = EnvVar(). 리팩토링 도구는 속성을 안전하게 이름을 변경할 수 있었고, 오류 메시지는 정확하게 유지되었습니다. 코드베이스는 150줄의 메타클래스 보일러플레이트가 줄어들었으며, 구성 키 불일치와 관련된 버그 보고 수가 줄어드는 것을 관찰했습니다.
__set_name__이 클래스 생성 생애주기 중에 정확히 언제 호출됩니까?
클래스 본체 실행이 완료되고 네임스페이스 사전이 채워진 직후 type.__new__에 의해 호출되지만, 부모 클래스에서 __init_subclass__가 호출되기 전에 호출됩니다. 이 타이밍은 설명자가 하위 클래스가 초기화되기 전에 자신의 상태를 최종화할 수 있도록 하기 때문에 중요합니다. 설명자가 이미 생성된 클래스에 속성을 추가할 때(예: setattr(MyClass, 'new_attr', descriptor()))에는 트리거되지 않습니다; 클래스 생성 프로토콜이 완료되었기 때문입니다. 이 구분 이해는 동적 클래스 조작에 필수적입니다.
이유는 무엇입니까? __set_name__이 소유 클래스와 이름을 인수로 받으며 self에서 유추하지 않습니까?
설명자 인스턴스는 클래스와 독립적으로 존재할 수 있으며, 클래스 생성 이전에 인스턴스화될 수 있고 이론적으로 여러 클래스에 할당될 수 있습니다(비록 드물지만). owner 인수는 설명자가 할당이 발생한 특정 클래스를 알 수 있도록 보장하며, 이는 상속을 올바르게 처리하는 데 필요합니다. 기본 클래스에 설명자가 정의되면 __set_name__은 기본 클래스를 사용하여 호출됩니다; 하위 클래스에서 새 인스턴스로 재정의되면 하위 클래스를 사용하여 호출됩니다. 이는 기본 클래스와 파생 클래스 간의 교차 오염 없이 클래스별 레지스트리를 가능하게 합니다.
__set_name__이 __set__ 및 __get__ 설명자 프로토콜 메서드와 어떻게 상호작용합니까?
__set_name__은 순수한 초기화 훅이며 속성 접근 프로토콜(__get__/__set__)에 참여하지 않습니다. 그러나 이 메서드는 작동에 필요한 컨텍스트를 제공하여 이러한 메서드가 올바르게 작동할 수 있도록 합니다. 일반적인 실수는 설명자가 하위 클래스에 의해 재정의되지 않고 상속될 때 __set_name__이 다시 호출될 것이라고 가정하는 것입니다. 동일한 설명자 인스턴스가 재사용되므로 __set_name__은 재호출되지 않습니다. 따라서 클래스별 상태를 추적하는 설명자는 상속을 처리하기 위해 __init_subclass__를 사용하거나 __get__에서 owner를 확인해야 합니다.