Pythonic
이 파트는 "Python 문법을 안다"와 "Python답게 설계할 수 있다" 사이의 차이를 메우는 섹션이다. descriptor, decorator, context manager, metaclass는 따로따로 배우면 산만하지만, 실제로는 전부 data model과 attribute lookup 위에 서 있다.
빠른 요약: Pythonic하다는 말의 핵심은 data model을 이해하고, 그 위에서 attribute lookup, descriptor, decorator, context manager, metaclass를 적절한 크기의 도구로 쓰는 것이다. 프레임워크의 "마법"도 대부분 이 조합이다.
이 파트에서 잡아야 할 질문
왜 `len(obj)`인가
Python 문법은 객체의 dunder method와 연결된다. 문법과 객체 모델이 분리되어 있지 않다.
왜 필드가 마법처럼 보이나
descriptor와 attribute lookup 순서를 알면 ORM, validation framework, computed field가 어떻게 동작하는지 읽힌다.
언제 dataclass면 충분한가
값 객체, 설정 객체, 내부 command payload처럼 "가벼운 구조체"가 필요할 때 dataclass가 매우 강하다. 반면 validation과 persistence까지 맡기려 들면 금방 무거워진다.
언제 decorator를 쓰고 언제 metaclass를 쓰나
둘 다 확장 도구지만, 개입 시점과 비용이 다르다. 작은 도구부터 쓰는 기준이 중요하다.
오픈소스는 어떻게 Pythonic하게 풀었나
Click, Requests, SQLAlchemy, Pydantic, FastAPI의 실제 코드 블록을 읽고 "왜 이 설계가 Pythonic한가"를 구조적으로 해석한다.
메타프로그래밍은 어디까지 써야 하나
`__init_subclass__`, `__set_name__`, class decorator, metaclass, import hook 중 어떤 도구를 언제 쓰는지 비용 중심으로 판단한다.
자원 경계는 어떻게 표현하나
context manager는 Python에서 scope와 cleanup을 가장 명확하게 표현하는 방식이다.
추천 순서
- Data Model
- Dataclasses
- Descriptors and Properties
- Open-source Pythonic Deep Dives
- Metaprogramming Advanced
- Decorators
- Context Managers
- Metaclasses
실전 연결
- FastAPI route decorator와 dependency wiring
- dataclass 기반 내부 command / value object
- Pydantic field annotation과 descriptor-like field access
- SQLAlchemy instrumented attribute와 class construction
- 오픈소스 코드에서 decorator/context manager/factory 패턴 읽기
- 메타프로그래밍 도구 선택(훅 우선순위) 기준 만들기