PEP 3000 – Python 3000

Author:: Guido van Rossum <guido at python.org>
Status:: Final
Type:: Process
Created:: 05-Apr-2006
Post-History:

Table of Contents

초록
명명
PEP 번호 체계
타임라인
호환성과 전환
구현 언어
메타 기여
참고 문헌
Copyright

번역·라이선스 안내

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

초록

이 PEP는 Python 3000 개발을 위한 지침을 정합니다. 이상적으로는 먼저 절차에 합의하고, 절차가 결정되고 명세된 후에야 기능에 대한 논의를 시작합니다. 실제로는 기능과 절차를 동시에 논의하게 될 것입니다. 특정 기능에 대한 논쟁이 절차에 대한 논의를 촉발하는 경우도 많을 것입니다.

Python 3000, Python 3.0, Py3K는 모두 같은 것을 가리키는 이름입니다. 이 프로젝트는 Python 3000이라고 부르며, 줄여서 Py3k라고도 합니다. 실제 Python 릴리스는 Python 3.0이라고 부르며, “python3.0 -V”가 출력하는 것도 이 이름입니다. 실제 파일 이름에는 Python 2.x에서 사용하는 것과 같은 명명 규칙을 사용합니다. 저는 실행 파일에 새 이름을 붙이거나 Python 소스 파일의 확장자를 바꾸고 싶지 않습니다.

PEP 번호 체계

Python 3000 PEP는 PEP 3000부터 번호가 매겨집니다. PEP 3000-3099는 메타 PEP이며, 절차 PEP이거나 정보 PEP일 수 있습니다. PEP 3100-3999는 기능 PEP입니다. PEP 3000 자체(이 PEP)는 특별합니다. 이 PEP는 Python 3000 메타 PEP들을 위한 메타 PEP입니다(다시 말해 절차를 정의하는 절차를 설명합니다). PEP 3100도 특별합니다. 이 PEP는 Python 3000 절차를 본격적으로 시작하기 전에 Python 3000에 포함하기로 (희망적으로) 선정된 기능들을 나열한 목록입니다. 끝으로 PEP 3099는 변경되지 않을 기능들의 목록입니다.

타임라인

Python 2.6과 3.0의 릴리스 일정이 담긴 PEP 361을 참조하십시오. 이 두 버전은 보조를 맞춰 함께 릴리스됩니다.

참고: 표준 라이브러리 개발은 3.0a1이 릴리스된 후 본격화될 것으로 예상됩니다.

저는 한동안 Python 2.x와 3.x 릴리스가 병행될 것으로 예상합니다. Python 2.x 릴리스는 전통적인 2.x.y 버그 수정 릴리스보다 더 오랫동안 계속될 것입니다. 일반적으로 2.(x+1) 버전이 릴리스되면 2.x의 버그 수정 버전 릴리스는 중단합니다. 하지만 3.0(최종판)이 릴리스된 후에도 최소 한두 번의 새로운 2.x 릴리스가 있을 것으로 예상하며, 아마 3.1이나 3.2 시기까지도 한참 이어질 것입니다. 이는 어느 정도 2.x 지원 지속에 대한 커뮤니티의 요구, 3.0의 수용도와 안정성, 그리고 자원봉사자들의 지구력에 달려 있을 것입니다.

저는 Python 3.1과 3.2가 2.x 시리즈에서 관례적이었던 것보다 3.0 이후 훨씬 빨리 릴리스될 것으로 예상합니다. 커뮤니티가 3.x에 만족하게 되면 3.x의 릴리스 패턴도 안정될 것입니다.

호환성과 전환

Python 3.0은 Python 2.x와의 하위 호환성을 깨뜨릴 것입니다.

Python 2.6 코드가 수정 없이 Python 3.0에서 실행되어야 한다는 요구 사항은 없습니다. 그 일부조차도 마찬가지입니다. (물론 아주 작은 부분집합은 있겠지만, 주요 기능이 빠져 있을 것입니다.)

Python 2.6은 다음 두 가지 방식으로 상위 호환성을 지원할 것입니다.

이 버전은 Python 3.0에서 더 이상 동작하지 않을 기능, 예를 들어 range()가 리스트를 반환한다고 가정하는 경우에 대해 동적으로(즉, 런타임에) 경고하는 “Py3k 경고 모드”를 지원할 것입니다.
많은 Py3k 기능의 백포트 버전을 포함할 것이며, 이 기능들은 __future__ 문을 통해 활성화하거나, (새 문법이 2.x에서 문법 오류가 되는 경우) 단순히 이전 문법과 새 문법을 나란히 사용할 수 있게 하는 방식으로 제공됩니다.

그 대신, 2.6의 상위 호환성 기능을 보완하는 별도의 소스 코드 변환 도구가 제공될 것입니다 [1]. 이 도구는 문맥 독립적인 소스 대 소스 변환을 수행할 수 있습니다. 예를 들어, apply(f, args)를 f(*args)로 변환할 수 있습니다. 그러나 이 도구는 데이터 흐름 분석이나 타입 추론을 할 수 없으므로, 이 예에서 apply가 예전의 내장 함수를 가리킨다고 단순히 가정합니다.

Python 2.6과 3.0을 동시에 지원해야 하는 프로젝트에 권장되는 개발 모델은 다음과 같습니다:

전체 커버리지에 가까운 훌륭한 단위 테스트를 갖추고 있어야 합니다.
프로젝트를 Python 2.6으로 이식하십시오.
Py3k 경고 모드를 켜십시오.
경고가 하나도 남지 않을 때까지 테스트하고 수정하십시오.
2to3 도구를 사용하여 이 소스 코드를 3.0 문법으로 변환하십시오. 출력 결과를 수동으로 편집하지 마십시오!
변환된 소스 코드를 3.0에서 테스트하십시오.
문제가 발견되면 소스 코드의 2.6 버전을 수정하고 3단계로 돌아가십시오.
릴리스할 때가 되면 2.6과 3.0 tarball(또는 릴리스에 사용하는 어떤 아카이브 형식이든)을 별도로 릴리스하십시오.

2.6 지원을 순수한 유지보수 수준으로 줄일 준비가 될 때까지는(즉, 어차피 일반적으로 2.6 코드를 유지보수 브랜치로 옮기게 될 시점까지는) 3.0 소스 코드를 편집하지 않는 것을 권장합니다.

추신. 전환 과정의 문제들을 자세히 설명하는 메타 PEP가 필요합니다.

구현 언어

Python 3000은 C로 구현될 것이며, 그 구현은 Python 2 코드 베이스를 발전시키는 방식으로 만들어질 것입니다. 이는 완전한 재작성의 위험성에 대한 제 견해(Joel Spolsky [2]와 공유하는 견해)를 반영합니다. 언어로서의 Python 3000은 Python 2를 비교적 온건하게 개선한 것이므로, 언어를 처음부터 다시 구현하려 하지 않음으로써 많은 것을 얻을 수 있습니다. 처음부터 새로 구현하려는 병행 작업에 반대하지는 않지만, 제 노력은 제가 가장 잘 아는 언어와 구현에 집중될 것입니다.