[Final] PEP 3000 - Python 3000

원문 링크: PEP 3000 - Python 3000

상태: Final 유형: Process 작성일: 05-Apr-2006

PEP 3000 – Python 3000

  • 작성자: Guido van Rossum
  • 상태: Final (최종)
  • 유형: Process (프로세스)
  • 생성일: 2006년 4월 5일

개요 (Abstract)

이 PEP는 Python 3000 개발을 위한 지침을 설정합니다. 이상적으로는 먼저 프로세스에 합의한 후, 해당 프로세스가 결정되고 명시된 후에야 기능 논의를 시작하는 것이 바람직합니다. 그러나 실제로는 기능과 프로세스 논의가 동시에 진행될 것이며, 특정 기능에 대한 논쟁이 프로세스 논의를 촉발하는 경우가 많을 것입니다.

명칭 (Naming)

Python 3000, Python 3.0, 그리고 Py3k는 모두 같은 것을 지칭하는 이름입니다. 이 프로젝트는 Python 3000 또는 줄여서 Py3k로 불립니다. 실제 Python 릴리스는 Python 3.0으로 지칭될 것이며, python3.0 -V 명령을 실행하면 이 이름이 출력될 것입니다. 실제 파일 이름은 Python 2.x에 사용된 것과 동일한 명명 규칙을 따를 것입니다. 실행 파일의 새 이름을 선택하거나 Python 소스 파일의 접미사를 변경할 계획은 없습니다.

PEP 번호 부여 (PEP Numbering)

Python 3000 관련 PEP는 PEP 3000부터 시작하는 번호가 부여됩니다.

  • PEP 3000-3099: 메타-PEP로, 프로세스 또는 정보성 PEP가 될 수 있습니다.
  • PEP 3100-3999: 기능 PEP입니다.

PEP 3000 자체(이 문서)는 Python 3000 메타-PEP를 위한 메타-PEP이며, 프로세스를 정의하는 프로세스를 설명합니다. PEP 3100 또한 특별합니다. 이는 Python 3000 프로세스를 본격적으로 시작하기 전에 (희망적으로) Python 3000에 포함되도록 선택된 기능들의 목록입니다. 마지막으로 PEP 3099는 변경되지 않을 기능들의 목록입니다.

타임라인 (Timeline)

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에 만족하면 안정화될 것입니다.

호환성 및 전환 (Compatibility and Transition)

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

Python 2.6 코드가 Python 3.0에서 수정 없이 실행되어야 한다는 요구 사항은 없습니다. 심지어 부분 집합도 아닙니다 (물론 아주 작은 부분 집합은 있겠지만, 주요 기능은 누락될 것입니다).

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

  1. "Py3k warnings mode"를 지원하여, range()가 리스트를 반환한다고 가정하는 것과 같이 Python 3.0에서 작동을 멈출 기능들에 대해 동적으로 (즉, 런타임에) 경고를 발생시킬 것입니다.
  2. 많은 Py3k 기능들의 백포트 (backported versions) 버전을 포함할 것입니다. 이는 __future__ 문을 통해 활성화되거나, 단순히 이전 구문과 새 구문을 나란히 사용할 수 있도록 허용함으로써 (새 구문이 2.x에서 문법 오류가 아닐 경우) 제공됩니다.

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

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

  1. 거의 완벽한 코드 커버리지를 가진 뛰어난 유닛 테스트 (unit tests)를 갖추어야 합니다.
  2. 프로젝트를 Python 2.6으로 포팅합니다.
  3. Py3k warnings mode를 고, 경고가 모두 사라질 때까지 테스트하고 편집합니다.
  4. 2to3 도구를 사용하여 이 소스 코드를 3.0 문법으로 변환합니다. 출력된 내용을 수동으로 편집하지 마세요!
  5. 변환된 소스 코드를 3.0에서 테스트합니다. 문제가 발견되면 2.6 버전의 소스 코드에서 수정하고 3단계로 돌아갑니다.
  6. 릴리스할 시기가 되면 2.6 및 3.0용 별도의 tarball (또는 사용 중인 아카이브 형식)을 릴리스합니다.

2.6 지원을 순수한 유지보수 단계로 줄일 준비가 될 때까지 (2.6 코드를 유지보수 브랜치로 옮길 시점) 3.0 소스 코드를 직접 편집하지 않는 것이 좋습니다.

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

구현 언어 (Implementation Language)

Python 3000은 C로 구현될 것이며, 이 구현은 Python 2 코드베이스의 진화된 형태로 파생될 것입니다. 이는 완전한 재작성 (complete rewrites)의 위험에 대한 저의 견해 (Joel Spolsky와 공유하는)를 반영합니다. Python 3000이 언어로서 Python 2에 비해 상대적으로 가벼운 개선이기 때문에, 언어를 처음부터 다시 구현하지 않음으로써 많은 이점을 얻을 수 있습니다. 저는 병렬적인 “처음부터 다시 구현” 노력에 반대하지 않지만, 저의 노력은 제가 가장 잘 아는 언어와 구현에 집중될 것입니다.

메타 기여 (Meta-Contributions)

이 PEP에 추가할 텍스트에 대한 제안은 저자가 기꺼이 수용합니다. 위에 언급된 주제 및 추가 주제에 대한 메타-PEP 초안은 더욱 환영합니다!

참고 자료 (References)

  • The 2to3 tool, in the subversion sandbox: http://svn.python.org/view/sandbox/trunk/2to3/
  • Joel on Software: Things You Should Never Do, Part I: http://www.joelonsoftware.com/articles/fog0000000069.html

이 문서는 퍼블릭 도메인에 공개되었습니다.

⚠️ 알림: 이 문서는 AI를 활용하여 번역되었으며, 기술적 정확성을 보장하지 않습니다. 정확한 내용은 반드시 원문을 확인하시기 바랍니다.

Comments