PEP 408 – 표준 라이브러리 __preview__ 패키지
- Author:
- Alyssa Coghlan <ncoghlan at gmail.com>, Eli Bendersky <eliben at gmail.com>
- Status:
- Rejected
- Type:
- Standards Track
- Created:
- 07-Jan-2012
- Python-Version:
- 3.3
- Post-History:
- 27-Jan-2012
- Resolution:
- Python-Dev message
번역·라이선스 안내
이 비공식 한국어 번역은 원문 Copyright 절의 Public Domain 조건에 따라 제공합니다. 원저자와 공식 원문은 그대로 표시합니다. 수정되지 않은 기준 원문 · 공식 최신판
초록
모듈이 공식적으로 Python의 일부가 되면 API 잠금과 하위 호환성 약속이 뒤따르기 때문에, 새 모듈을 Python 표준 라이브러리에 포함하는 과정이 어려워집니다. 이 PEP는 모듈을 위한 과도기 상태를 제안합니다. 즉, 표준 라이브러리에 완전히 채택되기 전에 마이너 릴리스 하나의 기간(약 18개월) 동안 특별한 __preview__ 패키지에 포함하는 것입니다. 한편으로 이 상태는 모듈에 공식적으로 Python 배포판의 일부가 되는 이점을 제공합니다. 다른 한편으로 코어 개발 팀은 모듈이 결국 표준 라이브러리에 완전히 포함될지, 또는 다음 릴리스에서 변경될 수 있는 모듈 API가 안정적일지에 대해 아무것도 약속하지 않는다고 명시적으로 밝힙니다.
PEP 거부
Guido는 Google App Engine의 비슷한 “labs” 네임스페이스에서 얻은 경험을 바탕으로, 잠정적 모듈을 문서에 그렇다고 명시적으로 표시하는 더 단순한 대안을 택하여 이 PEP를 기각했습니다 [3].
어떤 모듈이 다른 면에서는 표준 라이브러리에 포함하기에 적합하다고 여겨지지만 유지 보수 가능성이나 특정 API 세부 사항에 관한 우려가 남아 있다면, 그 모듈은 잠정적으로 채택될 수 있습니다. 그럴 가능성은 낮다고 여겨지지만, 남아 있는 우려가 타당한 것으로 드러나면 그러한 모듈은 폐지 예고 기간 없이 표준 라이브러리에서 제거될 수 있습니다.
같은 발표에서 Guido는 Matthew Barnett의 ‘regex’ 모듈 [4]을 Python 3.3 표준 라이브러리에 잠정적으로 추가하는 것을 명시적으로 승인했습니다(기존 ‘re’ 모듈을 그대로 대체하는 것이 아니라 ‘regex’라는 이름을 사용합니다).
제안 - __preview__ 패키지
Python 코어 개발 팀이 새 모듈을 표준 라이브러리에 포함해야 한다고 결정했지만 그 모듈의 API가 최적인지 완전히 확신하지 못하는 경우, 해당 모듈을 마이너 릴리스 하나 동안 __preview__라는 특별한 패키지에 둘 수 있습니다.
다음 마이너 릴리스에서 그 모듈은 표준 라이브러리로 “졸업”하거나(__preview__ 패키지를 떠나 네임스페이스 안의 본래 자리를 차지합니다), 거부되어 Python 소스 트리에서 완전히 제거될 수 있습니다. 모듈이 __preview__에서 마이너 릴리스 하나를 보낸 뒤 결국 표준 라이브러리로 졸업하게 되면, 그 API는 누적된 피드백에 따라 변경될 수 있습니다. 코어 개발 팀은 __preview__에 있는 모듈의 API 안정성과 하위 호환성을 명시적으로 보장하지 않습니다.
__preview__ 패키지에 들어가는 것은 모듈이 표준 라이브러리로 전환되기 시작한다는 것을 뜻합니다. 이는 코어 개발 팀이 표준 라이브러리의 다른 모듈과 마찬가지로 그 모듈에 대한 책임을 진다는 의미입니다.
어떤 모듈이 __preview__를 거쳐야 하는가
Python 표준 라이브러리에 추가하자고 제안되는 모듈 대부분은 __preview__에서 마이너 릴리스 하나를 거칠 것으로 예상합니다. 하지만 미리 정의된 API를 사용하는 모듈(예를 들어 기존 bz2 모듈의 API를 대체로 따르는 lzma)이나 Python 개발 커뮤니티에서 널리 받아들여진 API를 가진 모듈처럼 몇 가지 예외가 있을 수 있습니다.
어떤 경우든 표준 라이브러리에 추가하자고 제안되는 모듈은 __preview__를 거치든 직접 추가되든 PEP 2에서 정한 채택 조건을 충족해야 합니다.
이 제안의 목적이 표준 라이브러리에 새 모듈을 추가하는 과정을 더 어렵게 만드는 것이 아니라는 점을 강조하는 것이 중요합니다. 오히려 이 제안은 유용한 라이브러리를 더 많이 추가할 수단을 제공하려는 것입니다. 추가될 후보임이 분명한 모듈은 이전처럼 추가할 수 있습니다. API에 대한 불확실성 때문에 오랫동안 보류될 수 있었던 모듈도 이제는 __preview__ 패키지에서 인큐베이션 기간을 거쳐 Python과 함께 배포될 수단을 갖게 됩니다.
“졸업” 기준
원칙적으로 __preview__ 패키지에 있는 모듈 대부분은 결국 안정적인 표준 라이브러리로 졸업해야 합니다. 졸업하지 못하는 이유로는 다음과 같은 것이 있습니다:
- 모듈이 불안정하거나 취약한 것으로 드러났는데, 이를 유지 보수할 개발자의 지원이 충분하지 않을 수 있습니다.
- 프리뷰 릴리스 기간에 훨씬 더 나은 대안 모듈이 발견될 수 있습니다
기본적으로 이 결정은 코어 개발자들이 사안별로 내리게 됩니다. 여기서 강조할 점은, 어떤 릴리스에서 모듈이 __preview__ 패키지에 들어갔다고 해서 다음 릴리스에서도 그 모듈이 계속 Python의 일부로 남는다는 보장은 없다는 것입니다.
예시
example 모듈이 표준 라이브러리에 포함될 후보이지만, 일부 Python 개발자는 이 모듈이 해결하려는 문제에 가장 적합한 API를 제공한다고 확신하지 못한다고 가정해 봅시다. 그러면 이 모듈을 3.X 릴리스에서 __preview__ 패키지에 추가할 수 있으며, 다음과 같이 임포트할 수 있습니다:
from __preview__ import example
이후 3.X+1 릴리스에서 이 모듈이 정식 표준 라이브러리로 승격된다고 가정하면, 이 모듈은 라이브러리 내의 영구적인 위치로 옮겨집니다:
import example
그리고 __preview__에서 임포트하는 방식은 더 이상 동작하지 않습니다.
근거
핵심 개발 팀의 이점
현재 코어 개발자들은 표준 라이브러리에 새로운 인터페이스를 추가하는 것을 매우 꺼립니다. 릴리스에 공개되는 즉시 하위 호환성 문제 때문에 API 설계상의 실수가 그대로 고착되기 때문입니다.
모든 주요 API 추가를 한 번의 전체 릴리스 동안 일종의 미리 보기 메커니즘을 거치게 하면, 표준 하위 호환성 보장으로 API를 잠금 상태로 확정하기 전에 커뮤니티 피드백을 받을 수 있는 전체 릴리스 주기를 한 번 확보하게 됩니다.
또한 패키저에게 미리 보기 모듈을 선택 사항으로 간주해서는 안 된다는 점을 분명히 한다면, 미리 보기 모듈을 표준 라이브러리의 나머지 부분과 일찍부터 통합하기 시작할 수도 있습니다. 미리 보기 API와 표준 라이브러리의 나머지 부분 사이의 유일한 차이는 미리 보기 API가 일반적인 하위 호환성 보장에서 명시적으로 제외된다는 점입니다.
기본적으로 __preview__ 패키지는 사소한 API 설계상의 실수가 오랜 기간 고착될 위험을 낮추기 위한 것입니다. 현재는 특정 추가 사항이 원칙적으로 좋은 생각이라는 데 핵심 개발 팀의 합의가 있는 경우에도 이러한 우려 때문에 새로운 추가가 가로막힐 수 있습니다.
최종 사용자의 이점
미래의 최종 사용자에게 가장 폭넓은 이점은 더 나은 “즉시 사용 가능한(out-of-the-box)” 경험에 있습니다. “아, 작업 X를 위한 표준 라이브러리 도구는 형편없으니 대신 이 서드파티 라이브러리를 내려받으십시오”라는 말을 듣는 대신, 그 우수한 도구들을 임포트 한 번으로 바로 사용할 수 있을 가능성이 더 높아집니다.
개발자가 업스트림 의존성에 대해 실사를 수행해야 하는 환경(이 때문에 PyPI에 있는 자료 중 상당수는 비용 효율성이 크게 떨어지거나 아예 사용이 배제되기도 합니다)에서 핵심 이점은 __preview__ 패키지에 있는 모든 것이 적어도 다음 관점에서 분명히 python-dev의 관리 아래 있음을 보장한다는 데 있습니다.
- 라이선스: 기여자 라이선스 계약(Contributor Licensing Agreement)에 따라 PSF가 재배포합니다.
- 문서화: 모듈 문서는 표준 Python 문서화 도구를 통해 게시되고 구성됩니다(즉, ReST 소스를 사용하고, Sphinx로 출력을 생성하여 http://docs.python.org 에 게시합니다).
- 테스트: 모듈 테스트 스위트는 python.org 빌드봇 군에서 실행되며, 결과는 http://www.python.org/dev/buildbot 을 통해 게시됩니다.
- 이슈 관리: 버그와 기능 요청은 http://bugs.python.org 에서 처리됩니다.
- 소스 관리: 소프트웨어의 마스터 저장소는 http://hg.python.org 에 게시됩니다.
__preview__에 포함될 후보
Python 3.3의 경우, 현재 분명한 후보가 여럿 있습니다.
regex(http://pypi.python.org/pypi/regex)daemon(PEP 3143)ipaddr(PEP 3144)
향후 가능한 다른 사용 사례는 다음과 같습니다.
PEP 407과의 관계
PEP 407은 6개월마다 중간 릴리스를 할 수 있도록 핵심 Python 릴리스 주기를 변경할 것을 제안합니다(표준 라이브러리 업데이트로 한정될 수도 있습니다). 릴리스 주기가 이렇게 변경된다면, __preview__ 네임스페이스에 대해 다음 정책을 제안합니다:
- 장기 지원 릴리스에서는
__preview__네임스페이스가 항상 비어 있습니다. - 새 모듈은 장기 지원 릴리스 바로 다음에 오는 중간 릴리스에서만
__preview__네임스페이스에 받아들여집니다. - 추가된 모든 모듈은 다음 장기 지원 릴리스 전에 표준 라이브러리의 최종 위치로 옮겨지거나 완전히 제거됩니다.
기각된 대안과 변형
__future__ 사용
Python에는 이미 __future__ 모듈이라는 형태로 “미래를 내다보는” 네임스페이스가 있으므로, 이를 이 새로운 목적에 재사용할 수 없는 이유를 묻는 것은 타당합니다.
그렇게 하는 것이 적절하지 않은 이유는 두 가지입니다:
1. __future__ 모듈은 실제로 Python 인터프리터가 모듈을 컴파일하는 방식을 바꿀 수 있는 별도의 컴파일러 지시문 기능과 연결되어 있습니다. 미리 보기 패키지에는 그런 것이 필요하지 않습니다. 평범한 Python 패키지면 충분합니다.
2. __future__ 모듈에는 관련 기능이 컴파일러의 기본 동작이 된 지 한참 지난 뒤에도 이름이 영구히 유지될 것이라는 명시적인 약속이 따릅니다. 이 역시 미리 보기 패키지가 의도하는 바와 정확히 반대입니다. 미리 보기에 추가된 모든 이름은 언젠가 제거될 것이 거의 확실하며, 그 이유는 표준 라이브러리의 영구적인 위치로 옮겨지기 때문일 가능성이 가장 높지만, (커뮤니티 피드백을 통해 제안된 추가 사항이 돌이킬 수 없을 만큼 잘못되었다고 판단되는 경우) 서드파티 패키지 지위로 되돌아가기 때문일 수도 있습니다.
패키지 버전 관리
제안된 대안 중 하나는 [1] __preview__ 패키지에 명시적인 버전 관리를 추가하는 것, 즉 __preview34__와 같은 형태로 만드는 것이었습니다. 저희는 Python 3.X에서 __preview__에 있는 모듈이 Python 3.X+1에서 일반 표준 라이브러리 네임스페이스로 승격되거나 Python 소스 트리에서 완전히 사라진다고 단순하게 정의하는 편이 더 낫다고 생각합니다. _preview__ 패키지에 버전 관리를 도입하면 과정이 복잡해지고 이 제안의 주된 의도와도 잘 맞지 않습니다.
앞뒤 밑줄이 없는 패키지 이름 사용
__preview__ 대신 preview나 exp 같은 패키지 이름을 사용하자는 제안이 있었습니다 [1]. 이 제안은 “dunder” 패키지 이름(즉, 앞뒤에 이중 밑줄이 있는 이름)이 Python에서 전달하는 특별한 의미 때문에 논의 과정에서 기각되었습니다. 게다가 dunder가 아닌 이름은 일반적인 표준 라이브러리 API 안정성 보장을 암시하게 되는데, 이는 __preview__ 패키지의 의도가 아닙니다.
pickle 호환성 유지
릴리스 3.X에서 __preview__에 있는 모듈을 기반으로 피클된 클래스 인스턴스는, 해당 모듈이 더 이상 __preview__에 있지 않은 릴리스 3.X+1에서는 언피클할 수 없습니다. 이를 가능하게 하는 특별한 코드를 추가할 수도 있지만, 이는 하위 호환성을 암시하므로 이 제안의 취지에 어긋납니다. 따라서 이 PEP는 피클 호환성을 유지할 것을 제안하지 않습니다.
감사의 말
Dj Gilcrease가 Python에 __preview__ 패키지를 두자는 아이디어를 처음 제안했습니다 [2]. 그의 원래 제안은 __experimental__이라는 이름을 사용하지만, 저희는 __preview__가 이 패키지의 의미를 더 잘 전달한다고 생각합니다.
참고 문헌
Copyright
This document has been placed in the public domain.