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 표준 라이브러리에 포함하는 과정은 해당 모듈이 공식적으로 Python의 일부가 됨으로써 발생하는 API 고정과 하위 호환성 보장 때문에 제약을 받습니다. 이 PEP는 모듈을 표준 라이브러리에 정식으로 수용하기 전에 한 번의 마이너 릴리스 기간(약 18개월) 동안 특수한 __preview__ 패키지에 포함하는 과도기 상태를 제안합니다. 한편으로 이 상태는 해당 모듈이 공식적으로 Python 배포판의 일부가 됨으로써 얻는 이점을 제공합니다. 다른 한편으로 핵심 개발 팀은 해당 모듈이 최종적으로 표준 라이브러리에 정식 포함될 것인지 또는 API가 안정적인지에 관해 어떠한 약속도 하지 않으며, 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 설계상의 실수가 장기간 고착될 위험을 낮추기 위한 것입니다. 현재는 핵심 개발 팀이 특정 추가 기능을 원칙적으로 좋은 생각이라고 합의한 경우에도 이러한 우려가 새로운 추가를 가로막을 수 있습니다.
최종 사용자의 이점
향후 최종 사용자에게 가장 큰 이점은 더 나은 “즉시 사용 가능한” 경험에 있습니다. “작업 X를 위한 표준 라이브러리 도구는 형편없으니, 대신 이 서드파티 라이브러리를 다운로드하십시오”라는 말을 듣는 대신, 더 우수한 도구를 단순히 임포트하는 것만으로 사용할 가능성이 커집니다.
개발자가 업스트림 의존성을 실사해야 하는 환경에서는(PyPI에 있는 자료 중 상당 부분의 비용 효율성을 심각하게 떨어뜨리거나 아예 사용을 배제하게 되므로), __preview__ 패키지에 포함된 모든 항목이 적어도 다음 관점에서 python-dev의 명확한 관리 아래 있다는 점을 보장하는 것이 핵심 이점입니다.
- 라이선스: 기여자 라이선스 계약에 따라 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__ 모듈에는 이름이 영구적으로 유지된다는 명시적인 약속이 따르며,
이는 관련 기능이 컴파일러의 기본 동작이 된 후에도 훨씬 오랫동안 유지된다는 의미입니다. 다시 말해, 이는 프리뷰 패키지의 의도와 정확히 반대입니다. 프리뷰에 추가된 모든 이름은 언젠가 제거될 것이 거의 확실하며, 대부분은 표준 라이브러리의 영구적인 위치로 이동하기 때문이겠지만, 커뮤니티의 피드백에서 제안된 추가 사항이 회복할 수 없을 정도로 잘못되었다고 판단하는 경우 제3자 패키지 상태로 되돌아갈 가능성도 있습니다.
패키지 버전 관리
제안된 한 대안 [1]은 __preview__ 패키지에 명시적인 버전 관리를 추가하는 것이었습니다. 즉, __preview34__와 같이 하는 것입니다. Python 3.X에서 __preview__에 포함된 모듈은 Python 3.X+1에서 일반 표준 라이브러리 네임스페이스로 승격되거나 Python 소스 트리에서 완전히 사라진다고 단순히 정의하는 편이 낫다고 생각합니다. _preview__ 패키지의 버전을 관리하면 과정이 복잡해지고 이 제안의 주된 의도와도 잘 맞지 않습니다.
앞뒤에 밑줄이 없는 패키지 이름 사용
__preview__ 대신 preview나 exp와 같은 패키지 이름을 사용하자는 제안 [1]이 있었습니다. 이는 Python에서 “dunder” 패키지 이름, 즉 앞뒤에 이중 밑줄이 있는 이름이 전달하는 특별한 의미 때문에 논의에서 거부되었습니다. 게다가 dunder가 아닌 이름은 일반적인 표준 라이브러리 API 안정성 보장을 암시하지만, 이는 __preview__ 패키지의 의도가 아닙니다.
pickle 하위 호환성 유지
릴리스 3.X의 __preview__에 있는 모듈을 기반으로 피클된 클래스 인스턴스는, 해당 모듈이 __preview__에 더 이상 존재하지 않는 릴리스 3.X+1에서는 언피클할 수 없습니다. 이를 동작하게 만들기 위한 특수한 코드가 추가될 수도 있지만, 이는 하위 호환성을 암시하게 되므로 이 제안의 취지에 어긋납니다. 따라서 이 PEP는 피클 호환성을 유지하는 것을 제안하지 않습니다.
크레딧
Dj Gilcrease는 파이썬에 __preview__ 패키지를 두는 아이디어를 처음으로 제안했습니다 [2]. 그의 원래 제안은 __experimental__이라는 이름을 사용했지만, 저희는 __preview__가 이 패키지의 의미를 더 잘 전달한다고 생각합니다.
참고 자료
Copyright
This document has been placed in the public domain.