Following system colour scheme Selected dark colour scheme Selected light colour scheme

Python 개선 제안 한국어 번역

PEP 608 – 조정된 Python 릴리스

Author:
Miro Hrončok <miro at hroncok.cz>, Victor Stinner <vstinner at python.org>
Status:
Rejected
Type:
Standards Track
Created:
25-Oct-2019
Python-Version:
3.9
Table of Contents

번역·라이선스 안내

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

초록

선택된 프로젝트의 호환 가능한 버전을 사용할 수 있을 때까지 Python 릴리스를 차단하십시오.

Python 릴리스 관리자는 프로젝트가 호환되지 않더라도, 해당 프로젝트가 충분히 빨리 수정될 것이라고 판단하거나 문제의 심각도가 충분히 낮다고 판단하면 Python을 릴리스하기로 결정할 수 있습니다.

근거

이 PEP는 선택된 프로젝트의 유지 관리자를 Python 릴리스 주기에 참여시킵니다. 여러 가지 이점이 있습니다:

  • Python 최종 릴리스 전에 더 많은 버그를 발견합니다
  • Python 최종 릴리스 전에 호환되지 않는 변경 사항을 논의하고 되돌리는 것을 고려합니다
  • 새로운 Python 최종 버전이 릴리스될 때 호환되는 프로젝트 수를 늘립니다

Python 베타 단계에 참여하는 프로젝트가 너무 적습니다

현재 Python 베타 버전은 최종 3.x.0 릴리스 4개월 전에 사용할 수 있습니다.

베타 단계에서 보고된 버그는 쉽게 수정할 수 있으며, 충분히 심각하면 릴리스를 차단할 수 있습니다.

호환되지 않는 변경 사항은 베타 단계에서 논의합니다. 코드 업데이트 방법을 설명하는 문서를 개선하거나, 이러한 변경 사항을 되돌리는 것을 고려합니다.

점점 더 많은 프로젝트가 CI에서 Python의 마스터 브랜치로 테스트되더라도, 상위 50개 PyPI 프로젝트 중 너무 많은 프로젝트가 최종 Python 릴리스 후 몇 주 또는 심지어 몇 달이 지나서야 새로운 Python과 호환됩니다.

DeprecationWarning이 무시됨

Python에는 기능을 폐기하는 잘 정의된 프로세스가 있습니다. 기능을 제거하려면 최소 한 번의 Python 릴리스 동안 DeprecationWarning이 발생해야 합니다.

실제로 주요 Python 프로젝트에서는 DeprecationWarning 경고가 수년 동안 무시됩니다. 일반적으로 유지 관리자들은 경고가 너무 많기 때문에 경고를 단순히 무시한다고 설명합니다. 또한 DeprecationWarning은 기본적으로 표시되지 않습니다(__main__ 모듈 제외: PEP 565).

점점 더 많은 프로젝트가 경고를 오류로 처리하여 테스트 모음을 실행하고 있더라도(-Werror), Python 핵심 개발자들은 기능이 제거될 때 얼마나 많은 프로젝트가 손상되는지 여전히 알 수 없습니다.

조정 필요

최종 Python 릴리스 후에 문제와 호환되지 않는 변경 사항이 발견되고 논의되면 Python을 수정하는 일이 훨씬 더 복잡하고 비용이 많이 듭니다. API가 공식 최종 릴리스의 일부가 되면 Python은 전체 3.x 릴리스 수명 동안 하위 호환성을 제공해야 합니다. 일부 운영 체제는 버그가 있는 최종 릴리스와 함께 배포될 수 있으며, 업데이트되기까지 몇 달이 걸릴 수 있습니다.

최종 Python 릴리스 후에야 새로운 Python으로 업데이트되는 프로젝트가 너무 많으며, 이 때문에 Python이 릴리스될 때 새로운 Python 버전으로 대규모 애플리케이션을 실행하기가 거의 불가능합니다.

선택된 모든 프로젝트의 호환 가능한 버전을 사용할 수 있을 때까지 Python 릴리스를 차단할 것을 제안합니다.

더 짧은 Python 릴리스 일정

다음 두 PEP인 PEP 602: Annual Release Cycle for Python 및 PEP 605: A rolling feature release stream for CPython는새로운 기능을 더 신속히 제공하기 위해 Python을 더 자주 릴리스하고자 합니다.

문제는 각 Python 3.x 릴리스가 많은 프로젝트를 손상시킨다는 것입니다.

조정된 Python 릴리스는 손상된 프로젝트 수를 줄이고 새로운 Python 릴리스를 더 유용하게 만듭니다.

사양

기본적으로 선정된 모든 프로젝트의 호환 버전을 사용할 수 있을 때까지 Python 릴리스가 차단됩니다.

최종 Python 버전을 릴리스하기 전에 Python 릴리스 관리자는 선정된 각 프로젝트의 호환성 상태 보고서를 보내야 합니다. 진행 상황을 확인하고 문제를 가능한 한 빨리 감지하기 위해 각 베타 릴리스에서 이러한 보고서를 보내는 것이 권장됩니다.

프로젝트가 충분히 빨리 수정될 예정이라고 판단하거나 문제의 심각도가 충분히 낮다고 판단하는 경우, Python 릴리스 관리자는 프로젝트가 호환되지 않더라도 Python을 릴리스하기로 결정할 수 있습니다.

각 Python 릴리스 후 프로젝트 목록을 업데이트하여 프로젝트를 제거하고 새 프로젝트를 추가할 수 있습니다. 예를 들어 오래되어 사용되지 않는 의존성을 제거하고 새 의존성을 추가할 수 있습니다. 전체 프로세스가 Python 릴리스를 지나치게 오래 차단하지 않는다면 목록은 늘어날 수 있습니다.

지연을 제한하십시오.

다음 Python 버전과 관련된 빌드 또는 테스트 문제가 프로젝트에 보고되면 유지 관리자는 한 달 이내에 답변해야 합니다. 답변이 없으면 해당 프로젝트를 Python 릴리스를 차단하는 프로젝트 목록에서 제외할 수 있습니다.

여러 프로젝트가 이미 Python의 마스터 브랜치에서 CI를 통해 테스트되고 있습니다. Python 릴리스 초기에 문제를 감지할 수 있으므로 문제를 처리할 충분한 시간이 확보됩니다. 아직 다음 Python에서 테스트되지 않은 프로젝트에 대해 더 많은 CI를 추가할 수 있습니다.

선정된 프로젝트의 문제가 알려지면 Python 릴리스 관리자와 관련 프로젝트 유지 관리자가 사안별로 예외를 논의할 수 있습니다. 모든 문제가 Python 릴리스를 차단할 만큼 중요한 것은 아닙니다.

선정된 프로젝트

Python 릴리스를 차단하는 프로젝트 목록(총 27개):

  • 프로젝트(13개):
    • aiohttp
    • cryptography
    • Cython
    • Django
    • numpy
    • pandas
    • pip
    • requests
    • scipy
    • Sphinx(Python 빌드에 필요함)
    • sqlalchemy
    • pytest
    • tox
  • 직접 및 간접 의존성 (14개):
    • certifi (urllib3에 필요)
    • cffi (cryptography에 필요)
    • chardet (Sphinx에 필요)
    • colorama (pip에 필요)
    • docutils (Sphinx에 필요)
    • idna (Sphinx와 requests에 필요)
    • jinja2 (Sphinx에 필요)
    • MarkupSafe (Sphinx에 필요)
    • psycopg2 (Django에 필요)
    • pycparser (cffi에 필요)
    • setuptools (pip와 수많은 파이썬 프로젝트에 필요)
    • six (수많은 파이썬 프로젝트에 필요)
    • urllib3 (requests에 필요)
    • wheel (pip에 필요)

프로젝트 선정 방법

파이썬을 빌드하는 데 사용되는 프로젝트는 Sphinx처럼 목록에 포함되어야 합니다.

가장 인기 있는 프로젝트는 가장 많이 다운로드된 PyPI 프로젝트 중에서 선택됩니다.

프로젝트 의존성 대부분도 목록에 포함되는데, 이는 호환되지 않는 의존성 하나가 프로젝트 전체를 막을 수 있기 때문입니다. 목록 길이를 줄이기 위해 일부 의존성은 제외됩니다.

pytest나 tox 같은 테스트 의존성도 포함되어야 합니다. 프로젝트를 테스트할 수 없다면 새 버전을 출시할 수도 없습니다.

목록은 다음 파이썬으로 프로젝트를 이식하는 비용을 충분히 파악할 수 있을 만큼 길어야 하지만, 파이썬 릴리스를 너무 오래 막지 않을 만큼 짧아야 합니다.

물론 목록에 포함되지 않은 프로젝트도 다음 파이썬 버전에 관한 문제를 보고하고 다음 파이썬 버전에서 CI를 실행하도록 권장됩니다.

호환되지 않는 변경

여기서의 정의는 폭넓습니다: 프로젝트를 빌드하거나 테스트할 때 문제를 일으키는 모든 파이썬 변경 사항을 뜻합니다.

호환되지 않는 변경의 더 많은 예시는 PEP 606: Python Compatibility Version도 참조하십시오.

예시

호환되지 않는 변경에는 여러 종류가 있습니다:

  • 파이썬 빌드의 변경. 예를 들어, 파이썬 3.8은 (pymalloc을 나타내는) 'm'을 sys.abiflags에서 제거했는데, 이는 리눅스 배포판 같은 파이썬 벤더에 영향을 미칩니다.
  • C 확장 빌드의 변경. 예를 들어, Python 3.8은 더 이상 C 확장을 libpython에 링크하지 않으며, Python 3.7은 errno 모듈에 대한 os.errno 별칭을 제거했습니다.
  • 제거된 함수. 예를 들어, ABC 클래스에 대한 collections 별칭은 Python 3.9에서 제거되었습니다.
  • 변경된 함수 시그니처:
    • 이전에는 받아들여지던 타입을 거부(예: int만 받아들이고 float는 거부).
    • 새로운 필수 매개변수 추가.
    • 위치 인자 또는 키워드 인자로 사용 가능한 매개변수를 위치 전용으로 변환.
  • 동작 변경. 예를 들어, Python 3.8은 이제 XML 속성을 이름으로 정렬하는 대신 삽입 순서대로 직렬화합니다.
  • 새로운 경고. 점점 더 많은 프로젝트가 모든 경고를 오류로 취급하여 테스트되기 때문에, 새로운 경고는 어떤 것이든 프로젝트 테스트를 실패하게 만들 수 있습니다.
  • C API에서 제거된 함수.
  • C API에서 불투명하게 만들어진 구조체. 예를 들어, PyInterpreterState는 Python 3.8에서 불투명해졌으며, 이는 interp->modules에 접근하는 프로젝트를 손상시켰습니다(대신 PyImport_GetModuleDict()를 사용해야 합니다).

Python과 DeprecationWarning 정리하기

다음은 Zen of Python (PEP 20)의 좌우명 중 하나입니다:

이를 수행하는 명확한 방법이 하나–가급적 단 하나–있어야 합니다.

파이썬이 발전함에 따라 새로운 방식이 필연적으로 등장합니다. DeprecationWarning이 발생하여 새로운 방식을 사용하도록 제안하지만, 많은 개발자가 기본적으로 조용히 표시되는 이 경고를 무시합니다.

때때로 두 방식을 모두 지원하는 데 약간의 유지보수 비용이 들지만, 파이썬 핵심 개발자들은 파이썬 코드베이스와 표준 라이브러리를 정리하기 위해 예전 방식을 제거하는 쪽을 선호합니다. 이러한 종류의 변경은 하위 호환성이 없습니다.

파이썬 2 지원 종료와 함께 평소보다 더 많은 호환성 깨짐 변경이 예상되며, 이는 오래된 파이썬 코드를 정리할 좋은 기회입니다.

분산 CI

선택된 프로젝트들이 파이썬의 마스터 브랜치와 호환되는지 확인하는 작업은 분산 CI를 사용하여 자동화할 수 있습니다.

기존 CI를 재사용할 수 있습니다.

다음 파이썬 버전에서 아직 테스트되지 않은 프로젝트를 위해 새로운 CI를 추가할 수 있습니다.

다음 파이썬 버전에서 테스트할 때는 DeprecationWarning 경고를 오류로 취급하는 것이 좋습니다.

다음 파이썬 버전에서 프로젝트를 테스트하는 작업이 반드시 “필수”(전체 CI를 막는)일 필요는 없습니다. 파이썬 릴리스의 베타 단계 동안에는 실패가 있어도 괜찮습니다. 해당 작업은 최종 파이썬 릴리스에서만 통과하면 됩니다.