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)는 특별하며, Python 3000 메타-PEP를 위한 메타-PEP입니다(즉, 프로세스를 정의하기 위한 프로세스를 설명합니다). PEP 3100도 특별하며, 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은 다음 두 가지 방식으로 상위 호환성을 지원합니다.

“Py3k 경고 모드”를 지원하며, Python 3.0에서 작동을 멈출 기능에 대해 동적으로(즉, 실행 시) 경고합니다. 예를 들어 range()가 리스트를 반환한다고 가정하는 경우가 이에 해당합니다.
__future__ 문을 통해 활성화하거나, 새로운 구문이 2.x에서 구문 오류가 되는 경우 단순히 이전 구문과 새로운 구문을 나란히 사용할 수 있도록 하는 방식으로, 여러 Py3k 기능의 백포트 버전을 포함합니다.

대신 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 지원을 순수한 유지 관리 단계로 줄일 준비가 될 때까지 3.0 소스 코드를 편집하지 않는 것이 좋습니다(즉, 일반적으로 2.6 코드를 유지 관리 브랜치로 옮길 시점까지입니다).

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

구현 언어

Python 3000은 C로 구현되며, 구현은 Python 2 코드베이스의 진화 형태로 파생됩니다. 이는 완전한 재작성의 위험성에 대한 제 견해를 반영하며, 이 견해는 Joel Spolsky [2]와도 공유합니다. Python 3000은 언어로서 Python 2를 비교적 온건하게 개선한 것이므로, 언어를 처음부터 다시 구현하려고 시도하지 않음으로써 많은 것을 얻을 수 있습니다. 병렬적인 처음부터 구현하려는 노력에 반대하는 것은 아니지만, 제 노력은 제가 가장 잘 아는 언어와 구현에 집중될 것입니다.