PEP 3147 – PYC 저장소 디렉터리
- Author:
- Barry Warsaw <barry at python.org>
- Status:
- Final
- Type:
- Standards Track
- Created:
- 16-Dec-2009
- Python-Version:
- 3.2
- Post-History:
- 30-Jan-2010, 25-Feb-2010, 03-Mar-2010, 12-Apr-2010
- Resolution:
- Python-Dev message
번역·라이선스 안내
이 비공식 한국어 번역은 원문 Copyright 절의 Public Domain 조건에 따라 제공합니다. 원저자와 공식 원문은 그대로 표시합니다. 수정되지 않은 기준 원문 · 공식 최신판
초록
이 PEP는 설치된 여러 서로 다른 버전의 Python 인터프리터 간 Python 소스 코드 파일의 공유를 개선하는 Python의 임포트 메커니즘 확장을 설명합니다. 이는 둘 이상의 바이트 컴파일 파일(.pyc 파일)을 Python 소스 파일(.py 파일)과 같은 위치에 둘 수 있도록 함으로써 구현됩니다. 여기서 설명하는 확장은 Unladen Swallow (PEP 3146)가 활성화된 C Python에서 생성될 수 있는 JIT 출력과 같은, 서로 다른 Python 컴파일 캐시를 지원하는 데에도 사용할 수 있습니다.
배경
CPython은 소스 코드를 “바이트코드”로 컴파일하며, 성능상의 이유로 소스 파일이 변경될 때마다 이 바이트코드를 파일 시스템에 캐시합니다. 이렇게 하면 컴파일 단계를 건너뛸 수 있으므로 Python 모듈을 훨씬 빠르게 로드할 수 있습니다. 소스 파일이 foo.py인 경우 CPython은 소스 파일 바로 옆의 foo.pyc 파일에 바이트코드를 캐시합니다.
바이트코드 파일에는 32비트 빅 엔디언 숫자 두 개가 들어 있으며, 그 뒤에 마셜링된 [2] 코드 객체가 이어집니다. 32비트 숫자는 매직 넘버와 타임스탬프를 나타냅니다. Python이 바이트코드 형식을 변경할 때마다, 예를 들어 가상 머신에 새로운 바이트코드를 추가할 때마다 매직 넘버가 변경됩니다. 이를 통해 이전 버전의 VM용으로 빌드된 pyc 파일이 문제를 일으키지 않도록 합니다. 타임스탬프는 pyc 파일이 해당 파일을 생성하는 데 사용된 py 파일과 일치하는지 확인하는 데 사용됩니다. 매직 넘버 또는 타임스탬프 중 하나라도 일치하지 않으면 py 파일을 다시 컴파일하고 새 pyc 파일을 기록합니다.
실제로 pyc 파일이 Python 메이저 릴리스 간에 호환되지 않는다는 것은 잘 알려져 있습니다. Python 소스 코드에서 import.c [3]을 읽어 보면, 최근까지 새 CPython 메이저 릴리스가 나올 때마다 pyc 매직 넘버가 변경되었다는 사실을 알 수 있습니다.
근거
Ubuntu [4]와 Debian [5]같은 Linux 배포판은 사용자에게 동시에 둘 이상의 Python 버전을 제공합니다. 예를 들어 Ubuntu 9.10 Karmic Koala 사용자는 Python 2.5, 2.6, 3.1을 설치할 수 있으며, 기본값은 Python 2.6입니다.
이는 시스템에 설치된 서드파티 Python 소스 파일에 충돌을 일으킵니다. 한 번에 둘 이상의 Python 버전용으로 단일 Python 소스 파일을 컴파일할 수 없기 때문입니다. Python이 매칭되지 않는 매직 넘버를 가진 pyc 파일을 찾으면, 소스를 다시 컴파일하는 더 느린 과정으로 돌아갑니다. 따라서 시스템에 /usr/share/python/foo.py가 설치되어 있다면, 서로 다른 두 Python 버전이 pyc 파일을 두고 경쟁하며 소스가 컴파일될 때마다 해당 파일을 다시 씁니다. (이러한 배포판에서는 여러 버전의 표준 라이브러리가 실제로 설치되므로 표준 라이브러리에는 이 문제가 영향을 미치지 않습니다.)
또한 이러한 배포판의 운영 체제 패키저가 부담을 덜 수 있도록 배포 패키지에는 Python 버전 번호 [6]가 포함되지 않으며, 시스템에 설치된 모든 Python 버전에서 공유됩니다. 패키지에 Python 버전 번호를 넣으면 유지 관리가 악몽이 됩니다. 모든 패키지는 - 그리고 그 종속성 - 새로운 Python 릴리스가 배포판에 추가되거나 제거될 때마다 업데이트되어야 하기 때문입니다. 제공되는 패키지의 수가 워낙 많으므로 이러한 작업량은 감당할 수 없습니다.
(PEP 384)는 서로 다른 Python 버전 간 서드파티 확장 모듈의 바이너리 호환성 문제를 해결하기 위해 제안되었습니다.
이러한 배포판은 pyc 파일을 공유할 수 없으므로, 소스 코드는 여전히 공유하면서 결과로 생성된 pyc 파일을 공유되지 않는 위치에 배치하기 위한 정교한 메커니즘이 개발되었습니다. 예로는 심볼릭 링크 기반의 Debian 방식인 python-support [8] 및 python-central [9]이 있습니다. 이러한 접근 방식은 매우 다양한 사용자에게 Python 애플리케이션을 제공하기 위한 정책을 훨씬 더 복잡하고, 취약하며, 이해하기 어렵고, 파편화된 것으로 만듭니다. 상류 tarball보다 운영 체제 공급업체를 통해 Python을 얻는 사용자가 더 많다고 볼 수 있습니다. 따라서 이러한 공급업체에게 CPython의 pyc 공유 문제를 해결하는 일은 매우 높은 우선순위를 가집니다.
이 PEP는 이 문제에 대한 해결책을 제안합니다.
제안
Python의 임포트 메커니즘이 확장되어 모든 Python 패키지 디렉터리 내부의 단일 디렉터리에 바이트코드 캐시 파일을 작성하고 검색합니다. 이 디렉터리를 __pycache__라고 부릅니다.
또한 pyc 파일 이름에는 해당 파일이 컴파일된 Python 버전을 구분하는 매직 문자열(“태그”라고 함)이 포함됩니다. 이를 통해 하나의 Python 소스 파일에 대해 여러 바이트코드 컴파일 캐시 파일이 공존할 수 있습니다.
매직 태그는 구현에 따라 정의되지만, 구현 이름과 버전 번호의 약칭을 포함해야 합니다. 예를 들면 cpython-32입니다. 이 태그는 모든 Python 버전 사이에서 고유해야 하며, 매직 번호가 변경될 때마다 새 매직 태그를 정의해야 합니다. 따라서 Python 3.2의 pyc 파일 예시는 foo.cpython-32.pyc입니다.
매직 태그는 imp 모듈의 get_tag() 함수를 통해 사용할 수 있습니다. 이는 imp.get_magic() 함수와 대응합니다.
이 방식은 Python 패키지 디렉터리의 불필요한 파일을 줄이는 추가적인 이점도 제공합니다.
Python 소스 파일을 처음 임포트할 때 패키지 디렉터리에 __pycache__ 디렉터리가 아직 없으면 생성됩니다. 임포트된 소스의 pyc 파일은 매직 태그 형식의 이름을 사용하여 __pycache__ 디렉터리에 기록됩니다. __pycache__ 디렉터리 생성이나 그 안의 pyc 파일 생성 중 어느 하나라도 실패하더라도, 임포트는 pre-PEP 3147 환경에서와 마찬가지로 계속 성공합니다.
py 소스 파일이 없으면 __pycache__ 내부의 pyc 파일은 무시됩니다. 이를 통해 실수로 오래된 pyc 파일을 임포트하는 문제가 제거됩니다.
하위 호환성을 위해 Python은 pyc 전용 배포본도 계속 지원하지만, pyc 파일이 py 파일이 있었을 디렉터리, 즉 __pycache__ 디렉터리가 아닌 곳에 있을 때만 그렇게 합니다. __pycache__외부의 pyc 파일은 py 소스 파일이 없는 경우에만 임포트됩니다.
py_compile [15] 및 compileall [16]과 같은 도구는 PEP 3147 형식의 레이아웃을 자동으로 생성하도록 확장되지만, pyc 전용 배포 레이아웃을 생성하는 옵션도 제공합니다.
예제
실제로는 어떤 모습일까요?
alpha라는 이름의 Python 패키지가 있고, 그 안에 beta라는 이름의 서브패키지가 있다고 가정하겠습니다. 바이트코드 컴파일 전의 소스 디렉터리 레이아웃은 다음과 같은 모습일 수 있습니다.:
alpha/
__init__.py
one.py
two.py
beta/
__init__.py
three.py
four.py
이 패키지를 Python 3.2로 바이트코드 컴파일한 후에는 다음과 같은 레이아웃을 볼 수 있습니다.:
alpha/
__pycache__/
__init__.cpython-32.pyc
one.cpython-32.pyc
two.cpython-32.pyc
__init__.py
one.py
two.py
beta/
__pycache__/
__init__.cpython-32.pyc
three.cpython-32.pyc
four.cpython-32.pyc
__init__.py
three.py
four.py
참고: 목록 순서는 플랫폼에 따라 다를 수 있습니다.
Python의 새 버전 두 개가 설치되었으며, 하나는 Python 3.3이고 다른 하나는 Unladen Swallow라고 가정하겠습니다. 바이트코드 컴파일 후 파일 시스템은 다음과 같은 모습이 됩니다.:
alpha/
__pycache__/
__init__.cpython-32.pyc
__init__.cpython-33.pyc
__init__.unladen-10.pyc
one.cpython-32.pyc
one.cpython-33.pyc
one.unladen-10.pyc
two.cpython-32.pyc
two.cpython-33.pyc
two.unladen-10.pyc
__init__.py
one.py
two.py
beta/
__pycache__/
__init__.cpython-32.pyc
__init__.cpython-33.pyc
__init__.unladen-10.pyc
three.cpython-32.pyc
three.cpython-33.pyc
three.unladen-10.pyc
four.cpython-32.pyc
four.cpython-33.pyc
four.unladen-10.pyc
__init__.py
three.py
four.py
보시는 것처럼 Python 버전 식별자 문자열이 고유한 한, 임의의 개수의 pyc 파일이 공존할 수 있습니다. 이러한 식별자 문자열은 아래에서 더 자세히 설명합니다.
이 레이아웃의 장점은 __pycache__ 디렉터리는 일반적으로 무시할 수 있으므로, 일반적인 디렉터리 목록에 다음과 비슷한 내용이 표시된다는 점입니다.:
alpha/
__pycache__/
__init__.py
one.py
two.py
beta/
__pycache__/
__init__.py
three.py
four.py
이는 오늘날의 Python보다도 훨씬 덜 복잡합니다.
Python 동작
Python이 가져올 모듈(가령 foo)을 검색할 때 여러 상황 중 하나에 해당할 수 있습니다. 현재 Python 규칙에 따르면 “일치하는 pyc”라는 용어는 매직 넘버가 현재 인터프리터의 매직 넘버와 일치하고, 소스 파일의 타임스탬프가 pyc 파일의 타임스탬프와 정확히 일치한다는 뜻입니다.
사례 0: 정상 상태
Python이 모듈 foo를 가져오도록 요청받으면 foo.py 파일(또는 foo 패키지이지만, 이 논의에서는 중요하지 않습니다)을 해당 sys.path를 따라 검색합니다. 파일을 찾으면 Python은 일치하는 __pycache__/foo.<magic>.pyc 파일이 있는지 확인하고, 있다면 해당 pyc 파일을 로드합니다.
사례 1: 첫 번째 임포트
Python이 foo.py를 찾았을 때 __pycache__/foo.<magic>.pyc 파일이 없으면 Python은 이를 생성하며, 필요한 경우 __pycache__ 디렉터리도 생성합니다. Python은 foo.py 파일을 구문 분석하고 바이트코드로 컴파일한 뒤, 그 바이트코드를 __pycache__/foo.<magic>.pyc에 저장합니다.
사례 2: 두 번째 임포트
Python이 모듈 foo를 두 번째로(물론 다른 프로세스에서) 가져오도록 요청받으면, 다시 sys.path를 따라 foo.py 파일을 검색합니다. Python이 foo.py 파일을 찾으면 일치하는 __pycache__/foo.<magic>.pyc를 검색하고, 이를 찾으면 바이트코드를 읽어 평소처럼 계속 진행합니다.
사례 3: 소스가 없는 __pycache__/foo.<magic>.pyc
foo.py 파일이 어떤 이유로 제거되었지만 캐시된 pyc 파일은 파일 시스템에 여전히 남아 있을 수 있습니다. __pycache__/foo.<magic>.pyc 파일은 존재하지만 이를 생성하는 데 사용된 foo.py 파일이 존재하지 않으면, Python은 foo를 가져오도록 요청받을 때 ImportError를 발생시킵니다. 다시 말해, 소스 파일이 존재하지 않는 한 Python은 캐시 디렉터리에서 pyc 파일을 가져오지 않습니다.
사례 4: 레거시 pyc 파일과 소스가 없는 임포트
소스 파일이 옆에 존재하면 Python은 모든 레거시 pyc 파일을 무시합니다. 다시 말해, foo.py 파일 옆에 foo.pyc 파일이 존재하면 모든 경우에 pyc 파일이 무시됩니다.
다만 소스가 없는 배포를 계속 지원하기 위해, 소스 파일이 없으면 Python은 소스 파일이 있었을 위치에 단독 pyc 파일이 있는 경우 이를 가져옵니다.
사례 5: 읽기 전용 파일 시스템
소스가 읽기 전용 파일 시스템에 있거나 __pycache__ 디렉터리 또는 pyc 파일을 다른 이유로 쓸 수 없는 경우에도 모든 동일한 규칙이 적용됩니다. __pycache__가 내부의 pyc 파일을 쓸 수 없는 권한으로 작성된 경우에도 마찬가지입니다.
흐름도
다음은 모듈이 로드되는 방식을 설명하는 흐름도입니다.
대체 Python 구현
Jython [11], IronPython [12], PyPy [13], Pynie [14], Unladen Swallow와 같은 대체 Python 구현도 __pycache__ 디렉터리를 사용하여 해당 플랫폼에 적합한 컴파일 산출물을 저장할 수 있습니다. 예를 들어 Jython은 모듈의 클래스 파일을 __pycache__/foo.jython-32.class에 저장할 수 있습니다.
구현 전략
이 기능은 Python 3.2를 대상으로 하며, 해당 버전과 이후의 모든 버전에서 이 문제를 해결합니다. Python 2.7로 백포트될 수도 있습니다. 공급업체는 적절하다고 판단하는 대로 변경 사항을 이전 배포판으로 자유롭게 백포트할 수 있습니다. 이 기능을 Python 2로 백포트하는 경우, -U 플래그를 사용하면 foo.cpython-27u.pyc와 같은 파일을 기록할 수 있습니다.
기존 코드에 미치는 영향
이 PEP를 채택하면 Python 내부와 외부 모두에서 기존 코드와 관용적 사용 방식에 영향을 미칩니다. 이 절에서는 이러한 영향 중 일부를 열거합니다.
PEP 3147 지원 여부 감지
사용 중인 Python 버전이 PEP 3147 기능을 제공하는지 감지하는 가장 쉬운 방법은 다음 검사를 수행하는 것입니다.:
>>> import imp
>>> has3147 = hasattr(imp, 'get_tag')
__file__
Python 3에서는 모듈을 가져올 때 해당 모듈의 __file__ 속성이 소스 py 파일을 가리킵니다(Python 2에서는 pyc 파일을 가리킵니다). 패키지의 __file__은 해당 패키지의 __init__.py에 대한 py 파일을 가리킵니다. 예를 들면 다음과 같습니다.:
>>> import foo
>>> foo.__file__
'foo.py'
# baz is a package
>>> import baz
>>> baz.__file__
'baz/__init__.py'
이 PEP의 어떤 내용도 __file__의 의미를 변경하지 않습니다.
이 PEP는 모듈에 __cached__ 속성을 추가할 것을 제안하며, 이 속성은 항상 읽거나 기록한 실제 pyc 파일을 가리킵니다. 환경 변수 $PYTHONDONTWRITEBYTECODE가 설정되었거나, -B 옵션이 지정되었거나, 소스가 읽기 전용 파일 시스템에 있다면 __cached__ 속성은 pyc 파일이 존재하지 않았을 경우 작성되었을 위치를 가리킵니다. 물론 이 위치의 경로에는 __pycache__ 하위 디렉터리가 포함됩니다.
pyc 파일을 지원하지 않는 대체 Python 구현에서는 __cached__ 속성이 의미가 있는 임의의 정보를 가리킬 수 있습니다. 예를 들어 Jython에서는 모듈의 .class 파일인 __pycache__/foo.jython-32.class일 수 있습니다. 일부 구현은 모듈을 생성하는 데 여러 컴파일 파일을 사용할 수 있으며, 이 경우 __cached__는 튜플일 수 있습니다. __cached__의 정확한 내용은 Python 구현별로 다릅니다.
합리적인 값을 계산할 수 없는 경우 구현에서는 __cached__를 None으로 설정하는 것이 좋습니다.
py_compile 및 compileall
Python에는 내장 import 메커니즘과 별도로 Python 모듈을 컴파일할 수 있도록 지원하는 두 모듈, py_compile [15]와 compileall [16]이 포함되어 있습니다. 특히 py_compile은 바이트코드 컴파일을 잘 알고 있으므로, 이 모듈들은 새 레이아웃을 이해하도록 업데이트됩니다. 기존 .pyc 바이트코드 컴파일 파일 경로명을 기록할 수 있도록 compileall에 -b 플래그가 추가됩니다.
bdist_wininst 및 Windows 설치 프로그램
이러한 도구도 설치 시 모듈을 명시적으로 컴파일합니다. 이 도구들이 py_compile과 compileall을 사용하지 않는다면, 새 레이아웃을 이해하도록 수정해야 합니다.
파일 확장자 검사
.pyc로 끝나는 파일을 검사한 다음 마지막 문자를 단순히 잘라 내 대응하는 .py 파일을 찾는 코드가 일부 존재합니다. 이 PEP가 구현되면 이 코드는 명백히 실패합니다.
이 사용 사례를 지원하기 위해 imp 패키지에 두 개의 새 메서드를 추가합니다 [17]:
imp.cache_from_source(py_path)->pyc_pathimp.source_from_cache(pyc_path)->py_path
대체 구현은 이 PEP에 대한 자체 지원을 바탕으로 합리적인 값을 반환하도록 이러한 함수를 자유롭게 재정의할 수 있습니다. 구현 또는 적용 중인 PEP 302 로더가 어떤 이유로든 적절한 파일 이름을 계산할 수 없는 경우 이러한 메서드는 None을 반환할 수 있습니다. 예외를 발생시켜서는 안 됩니다.
백포트
3.2 이전 버전의 Python(그리고 2.7도 가능)에서는 이 PEP를 백포트할 수 있습니다. 그러나 Python 3.2(그리고 2.7도 가능)에서는 이 동작이 기본적으로 활성화되며, 실제로 이전 동작을 대체합니다. 백포트는 기본적으로 이전 레이아웃을 지원해야 합니다. 기능을 활성화하려면 $PYTHONENABLECACHEDIR라는 환경 변수 또는 -Xenablecachedir라는 명령줄 스위치를 사용하여 PEP 3147을 지원할 것을 제안합니다.
Makefile 및 기타 종속성 도구
.pyc 파일에 대한 종속성을 계산하는 Makefile 및 기타 도구(예를 들어 .pyc가 없을 때 소스를 바이트코드로 컴파일하는 도구)는 새 경로를 확인하도록 업데이트해야 합니다.
대안
이 절에서는 PEP를 개발하는 동안 고려되었으나 거부된 몇 가지 대안적 접근 방식이나 세부 사항을 설명합니다.
16진수 매직 태그
__pycache__ 디렉터리 내부의 pyc 파일에는 파일 이름에 매직 태그가 포함됩니다. 이는 임포터가 사용하는 실제 매직 번호를 기억하기 쉽게 나타낸 태그입니다. 이진 매직 번호의 16진수 표현 [10]을 고유 식별자로 사용할 수도 있었습니다. 예를 들어 Python 3.2에서는:
>>> from binascii import hexlify
>>> from imp import get_magic
>>> 'foo.{}.pyc'.format(hexlify(get_magic()).decode('ascii'))
'foo.580c0d0a.pyc'
하지만 이는 사람이 사용하기에 그다지 친숙하지 않으므로, 이 PEP에서는 매직 태그를 제안합니다.
PEP 304
이 PEP의 목표와 철회된 PEP 304의 목표 사이에는 어느 정도 겹치는 부분이 있습니다. 그러나 PEP 304에서는 사용자가 pyc 파일을 저장할 섀도 파일 시스템 계층 구조를 만들 수 있도록 허용합니다. pyc 파일을 위한 섀도 계층 구조라는 이 개념을 이 PEP의 목적을 달성하는 데 사용할 수 있습니다. 철회된 이유를 PEP 304가 명시하지는 않지만, 섀도 디렉터리에는 여러 문제가 있습니다. 섀도 pyc 파일의 위치를 쉽게 찾을 수 없으며, 시스템과 최종 사용자 모두가 $PYTHONBYTECODE 환경 변수를 올바르고 일관되게 사용해야 한다는 점에 의존합니다. 또한 전역적인 영향도 있습니다. 즉, 시스템은 pyc 파일을 섀도 처리하려 할 수 있지만 사용자는 원하지 않을 수 있는데, 이 PEP는 전부 아니면 전무한 접근 방식만 정의합니다.
이 문제의 예로, 데이터 파일의 위치를 찾는 일반적인(하지만 취약한) Python 관용구는 다음과 같은 작업을 수행하는 것입니다.:
from os import dirname, join
import foo.bar
data_file = join(dirname(foo.bar.__file__), 'my.dat')
이는 문제가 될 수 있습니다. foo.bar.__file__는 섀도 디렉터리에 있는 pyc 파일의 위치를 제공하며, 그 위치에서 소스 디렉터리를 기준으로 my.dat 파일을 찾는 것이 불가능할 수 있기 때문입니다.
팻 바이트 컴파일 파일
이 PEP의 이전 버전에서는 “팻” Python 바이트코드 파일을 설명했습니다. 이러한 파일은 하나의 pyf 파일 안에 여러 pyc 파일에 해당하는 내용을 포함하고, 적절한 매직 넘버를 키로 사용하는 조회 테이블을 포함합니다. 이는 처음 5개의 병렬 Python 구현을 상당히 효율적으로 지원할 수 있는 확장 가능한 파일 형식이었으며, 필요한 만큼 pyf 바이트코드 객체를 확장할 수 있도록 확장용 조회 테이블도 제공했습니다.
팻 바이트 컴파일 파일은 상당히 복잡했고 본질적으로 해결하기 어려운 경쟁 조건을 도입했으므로, 현재처럼 디렉터리를 사용하는 단순화 방안이 제안되었습니다. zip 파일을 팻 pyc 파일 형식으로 사용하는 경우에도 동일한 문제가 적용됩니다.
여러 파일 확장자
PEP 작성자는 여러 개의 얇은 바이트 컴파일 파일을 같은 위치에 두되, Python 버전을 나타내기 위해 서로 다른 파일 확장자를 사용하는 방식도 고려했습니다. 예를 들어 foo.pyc25, foo.pyc26, foo.pyc31 등입니다. 이렇게 서로 다른 파일을 너무 많이 작성해야 하는 번거로움 때문에 이 방식은 거부되었습니다. 여러 확장자 방식에서는 파일 확장자에 의존하는 도구를 업데이트하기가 더 어려워지며, 이는 계속 진행해야 하는 작업이 됩니다.
.pyc
__pycache__ 디렉터리를 .pyc 또는 다른 점 파일 이름으로 부르자는 제안이 있었습니다. 이렇게 하면 *nix 시스템에서 디렉터리가 숨겨집니다. BDFL [20]를 비롯하여 이 제안이 거부된 이유는 많습니다. 점 파일은 일부 플랫폼에서만 특별하게 취급되며, 실제로는 이러한 파일을 사용자에게서 완전히 숨기고 싶지 않습니다.
참조 구현
이 코드에 대한 작업은 Python 3.2에 병합할 준비가 될 때까지 Launchpad의 Bazaar 브랜치에서 추적됩니다 [22]. 진행 중인 diff도 [23]에서 볼 수 있으며, 새로운 변경 사항이 업로드되면 자동으로 업데이트됩니다.
2010-04-01 기준으로 Rietveld 코드 검토 이슈 [24]가 열렸습니다(아니요, 만우절 농담이 아닙니다 :).
참고 자료
[21] importlib: https://docs.python.org/3.1/library/importlib.html
감사의 말
Barry Warsaw의 원래 아이디어는 용량이 큰 Python 바이트코드 파일을 만드는 것이었습니다. Martin von Loewis는 PEP의 초기 초안을 검토하고 기존의 pyc 및 pyo 파일을 디렉터리에 저장하도록 단순화할 것을 제안했습니다. 그 밖에도 많은 사람이 이 PEP의 초기 버전을 검토하고 유용한 피드백을 제공했으며, 다음 사람들을 비롯하되 이에 국한되지 않습니다.
- David Malcolm
- Josselin Mouette
- Matthias Klose
- Michael Hudson
- Michael Vogt
- Piotr Ożarowski
- Scott Kitterman
- Toshio Kuratomi
Copyright
This document has been placed in the public domain.