PEP 411 – Python 표준 라이브러리의 잠정 패키지

Author:: Alyssa Coghlan <ncoghlan at gmail.com>, Eli Bendersky <eliben at gmail.com>
Status:: Superseded
Type:: Informational
Created:: 10-Feb-2012
Python-Version:: 3.3
Post-History:: 10-Feb-2012, 24-Mar-2012

Table of Contents

초록
제안 - 문서화된 잠정 상태
근거
- 핵심 개발 팀이 얻는 이점
- 최종 사용자가 얻는 이점
표준 라이브러리 잠정 포함 후보
기각된 대안과 변형
참고 문헌
Copyright

번역·라이선스 안내

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

Note

이 PEP는 대체됨(Superseded)으로 표시되었습니다. 이 PEP가 작성되고 10년이 지나고 보니, 이 기능은 표준 라이브러리를 관리하는 데 거의 사용되지 않는다는 것이 경험으로 드러났습니다. 또한 이 기능은 사람들이 잠정 모듈에 지나치게 의존하는 것을 막는 데에도 도움이 되지 않았으며, 그 결과 변경 사항이 여전히 커뮤니티에 상당한 문제를 일으킬 수 있습니다.

초록

새 패키지를 Python 표준 라이브러리에 포함하는 과정은, 패키지가 공식적으로 Python의 일부가 되면서 수반되는 API 잠금과 하위 호환성 약속 때문에 어려워집니다. 이 PEP는 표준 라이브러리 패키지를 기능 릴리스 한 번의 기간 동안 “잠정(provisional)” 상태로 표시하는 방법론을 설명합니다. 잠정 패키지는 “안정(stable)” 상태로 “졸업”하기 전에 API가 수정될 수 있습니다. 한편으로, 이 상태는 패키지가 공식적으로 Python 배포의 일부가 됨으로써 얻는 이점을 제공합니다. 다른 한편으로 핵심 개발 팀은 패키지 API의 안정성에 대해 어떠한 약속도 하지 않으며 API가 다음 릴리스에서 변경될 수 있다고 명시적으로 밝힙니다. 가능성이 낮은 결과로 여겨지기는 하지만, API나 유지 관리에 대한 우려가 타당한 것으로 드러나면 이러한 패키지는 폐지 예고 기간 없이 표준 라이브러리에서 제거될 수도 있습니다.

제안 - 문서화된 잠정 상태

Python 코어 개발 팀이 새 패키지를 표준 라이브러리에 포함해야 한다고 결정했지만 그 패키지의 API가 최적인지 완전히 확신하지 못할 때마다, 해당 패키지를 포함하되 “잠정(provisional)”으로 표시할 수 있습니다.

다음 기능 릴리스에서 패키지는 표준 라이브러리의 일반적인 “안정(stable)” 상태로 “졸업”하거나, 잠정 상태로 남거나, 거부되어 Python 소스 트리에서 완전히 제거될 수 있습니다. 패키지가 잠정 상태를 거쳐 결국 안정 상태로 졸업하게 되는 경우, 누적된 피드백에 따라 API가 변경될 수 있습니다. 핵심 개발 팀은 잠정 패키지의 API 안정성과 하위 호환성에 대해 명시적으로 어떠한 보장도 하지 않습니다.

패키지를 잠정으로 표시하기

패키지는 해당 문서 페이지와 독스트링에 있는 안내문을 통해 잠정으로 표시됩니다. 문서 페이지 상단에 다음 단락이 참고(note)로 추가됩니다:

<X> 패키지는 잠정적으로 표준 라이브러리에 포함되었습니다. 코어 개발자가 필요하다고 판단하면 하위 호환되지 않는 변경(패키지 제거까지 포함)이 일어날 수 있습니다.

그리고 “잠정적으로(provisional basis)”라는 문구는 용어집 항목 “잠정 패키지(provisional package)”로 연결되며, 이 항목은 다음과 같이 정의됩니다:

잠정 패키지는 표준 라이브러리의 하위 호환성 보장에서 의도적으로 제외된 패키지입니다. 그러한 패키지에 대한 큰 변경은 예상되지 않지만, 잠정으로 표시되어 있는 동안에는 코어 개발자가 필요하다고 판단하면 하위 호환되지 않는 변경(패키지 제거까지 포함)이 일어날 수 있습니다. 이러한 변경은 이유 없이 이루어지지 않습니다 – 패키지를 포함하기 전에 놓친 심각한 결함이 발견된 경우에만 이루어집니다.
이 과정을 통해 표준 라이브러리는 문제가 있는 설계 오류를 오랜 기간 고착시키지 않으면서 시간이 지남에 따라 계속 발전할 수 있습니다. 자세한 내용은 PEP 411을 참조하십시오.

패키지 독스트링의 시작 부분에 다음 내용이 추가됩니다:

이 패키지의 API는 현재 잠정 상태입니다. 자세한 내용은 문서를 참조하십시오.

패키지를 잠정 상태에서 안정 상태로 옮기려면 문서 페이지와 독스트링에서 이러한 안내문을 제거하기만 하면 됩니다.

어떤 패키지가 잠정 상태를 거쳐야 하는가

Python 표준 라이브러리에 추가하자고 제안되는 패키지 대부분은 잠정 상태로 기능 릴리스를 한 번 거칠 것으로 예상합니다. 다만 몇 가지 예외가 있을 수 있습니다. 미리 정의된 API를 사용하는 패키지(예를 들어 기존 bz2 패키지의 API를 대체로 따르는 lzma)나 Python 개발 커뮤니티에서 널리 받아들여진 API를 가진 패키지가 그러한 예입니다.

어떤 경우든 표준 라이브러리에 추가하자고 제안되는 패키지는 잠정 상태를 거치든 직접 추가되든 PEP 2에서 정한 채택 조건을 충족해야 합니다.

“졸업” 기준

원칙적으로 대부분의 잠정 패키지는 결국 안정된 표준 라이브러리로 졸업해야 합니다. 졸업하지 못하는 몇 가지 이유는 다음과 같습니다:

패키지가 불안정하거나 취약한 것으로 드러났는데, 이를 유지 보수할 개발자 지원이 충분하지 않을 수 있습니다.
미리 보기 릴리스 기간에 훨씬 더 나은 대체 패키지가 발견될 수 있습니다.

본질적으로, 결정은 코어 개발자가 사안별로 내립니다. 여기서 강조할 점은 어떤 릴리스에서 패키지가 “잠정”으로 표준 라이브러리에 포함되었다고 해서 다음 릴리스에서도 계속 Python의 일부로 남는다는 보장은 없다는 것입니다. 동시에 잠정 패키지를 변경하기 위한 기준은 상당히 높습니다. 대부분의 잠정 패키지는 졸업할 때 API 대부분이 변경되지 않을 것으로 예상합니다. 철회는 드물 것으로 예상합니다.

근거

핵심 개발 팀이 얻는 이점

현재 코어 개발자들은 표준 라이브러리에 새 인터페이스를 추가하는 것을 매우 꺼립니다. 인터페이스가 릴리스에 공개되는 순간 하위 호환성 문제 때문에 API 설계상의 실수가 그대로 굳어지기 때문입니다.

모든 주요 API 추가를 일종의 임시 메커니즘을 거쳐 한 번의 릴리스 전체 기간 동안 시험하게 하면, 표준 하위 호환성 보장으로 API를 잠금 상태로 고정하기 전에 한 릴리스 주기 동안 커뮤니티 피드백을 받을 수 있습니다.

또한 패키저들에게 잠정 패키지를 선택 사항으로 간주해서는 안 된다는 점을 분명히 해 두기만 하면, 잠정 패키지를 표준 라이브러리의 나머지 부분과 일찍부터 통합하기 시작할 수도 있습니다. 잠정 API와 표준 라이브러리의 나머지 부분 사이의 유일한 차이점은 잠정 API가 일반적인 하위 호환성 보장에서 명시적으로 제외된다는 것입니다.

최종 사용자가 얻는 이점

미래의 최종 사용자에게 가장 폭넓은 이점은 더 나은 “즉시 사용 가능한” 경험에 있습니다. “아, 작업 X를 위한 표준 라이브러리 도구는 형편없으니 대신 이 서드파티 라이브러리를 내려받으십시오”라는 말을 듣는 대신, 그 우수한 도구들을 import 한 번으로 바로 사용할 수 있을 가능성이 커집니다.

개발자가 업스트림 의존성에 대해 실사를 수행해야 하는 환경(이 때문에 PyPI에 있는 자료 상당수의 비용 효율성이 크게 떨어지거나 아예 사용할 수 없게 되기도 합니다)에서 핵심 이점은 잠정 상태의 모든 패키지가 적어도 다음 관점에서 명확히 python-dev의 보호 아래 있도록 보장한다는 데 있습니다:

라이선스: 기여자 라이선스 협약(Contributor Licensing Agreement)에 따라 PSF가 재배포합니다.
문서화: 패키지 문서는 표준 Python 문서화 도구를 통해 게시되고 구성됩니다(즉, ReST 소스로 작성하고 Sphinx로 출력을 생성하여 http://docs.python.org에 게시합니다).
테스트: 패키지 테스트 스위트는 python.org buildbot 무리에서 실행되며, 결과는 http://www.python.org/dev/buildbot을 통해 게시됩니다.
이슈 관리: 버그와 기능 요청은 http://bugs.python.org에서 처리됩니다
소스 관리: 소프트웨어의 마스터 저장소는 http://hg.python.org에 게시됩니다.

표준 라이브러리 잠정 포함 후보

Python 3.3에는 현재 명확한 후보가 여럿 있습니다:

regex (http://pypi.python.org/pypi/regex) - Guido가 승인함 [1].
daemon (PEP 3143)
ipaddr (PEP 3144)

그 밖에 향후 가능한 사용 사례는 다음과 같습니다:

개선된 HTTP 모듈 (예: requests)
HTML 5 파싱 지원 (예: html5lib)
개선된 URL/URI/IRI 파싱
표준 이미지 API (PEP 368)
임포트 상태의 캡슐화 개선 (PEP 406)
표준 이벤트 루프 API (PEP 3153)
Python 3용 WSGI의 바이너리 버전(예: PEP 444)
제네릭 함수 지원 (예: simplegeneric)