나는 파이썬이 인터프리터 언어라는 것을 이해하도록 주어졌다...
그러나 내 Python 소스 코드를 보면 Windows에서 "Compiled Python Files"로 식별하는 .pyc
이것들은 어디에서 오는가?
질문자 :froadie
나는 파이썬이 인터프리터 언어라는 것을 이해하도록 주어졌다...
그러나 내 Python 소스 코드를 보면 Windows에서 "Compiled Python Files"로 식별하는 .pyc
이것들은 어디에서 오는가?
나는 파이썬이 인터프리터 언어라는 것을 이해하도록 주어졌다...
이 대중적인 밈은 정확하지 않거나 오히려 (자연어) 언어 수준에 대한 오해로 구성되어 있습니다. 비슷한 실수는 "성경은 양장본 책입니다"라고 말하는 것입니다. 그 비유를 설명하자면...
"성경"은 책의 한 부류 라는 의미에서 "책"입니다. "성경의 사본"으로 확인된 책들은 근본적인 공통점을 가지고 있다고 가정합니다. 기본적으로 간주되지 않는 수많은 측면에서 완벽하게 다를 수 있습니다. 제본 유형, 제본 색상, 인쇄에 사용된 글꼴, 일러스트레이션(있는 경우), 쓰기 가능한 여백이 넓은지 여부, 내장 책갈피의 수 및 종류 , 등등.
성경의 전형적인 인쇄가 실제로 양장본 제본으로 되어 있을 가능성이 매우 높습니다. 결국, 그것은 일반적으로 반복해서 읽고, 여러 곳에 책갈피를 지정하고, 주어진 장과 구절 포인터를 검색하면서 엄지손가락을 치켜들어야 하는 책입니다. , 등등, 그리고 좋은 양장본 바인딩은 주어진 사본을 그러한 사용 하에서 더 오래 지속시킬 수 있습니다. 그러나 이것들은 주어진 실제 책 개체가 성경의 사본인지 여부를 결정하는 데 사용할 수 없는 일상적인(실용적인) 문제입니다. 페이퍼백 인쇄가 완벽하게 가능합니다!
유사하게, 파이썬은 몇 가지 근본적인 측면(구문, 명시적으로 다를 수 있는 부분을 제외한 대부분의 의미론)에서 모두 유사해야 하지만 완전히 허용되는 언어 구현 클래스를 정의한다는 의미에서 "언어"입니다. 제공된 소스 파일을 처리하는 방법, 소스를 일부 하위 수준 형식으로 컴파일하는지 여부(그렇다면 어떤 형식인지 여부, 그러한 형식을 저장하는지 여부를 포함하여) 거의 모든 "구현" 세부 사항에서 다릅니다. 컴파일된 양식, 디스크 또는 다른 곳으로), 해당 양식을 실행하는 방법 등.
고전적인 구현인 CPython은 종종 간단히 "Python"이라고 부르지만 Microsoft의 IronPython(CLR 코드, 즉 ".NET"으로 컴파일됨), Jython과 나란히 여러 프로덕션 품질 구현 중 하나일 뿐입니다. (JVM 코드로 컴파일됨), PyPy(파이썬 자체로 작성되었으며 "적시" 생성 기계 언어를 포함하여 다양한 "백엔드" 형식으로 컴파일할 수 있음). 표면적으로 다른 많은 책 개체가 모두 성경(=="성경의 사본")이 될 수 있는 것처럼 그것들은 모두 파이썬(=="파이썬 언어의 구현")입니다.
특히 CPython에 관심이 있는 경우: 소스 파일을 Python 고유의 하위 수준 형식("바이트코드"라고 함)으로 컴파일하고 필요할 때 자동으로 컴파일합니다(소스 파일에 해당하는 바이트코드 파일이 없는 경우 또는 바이트코드 파일이 소스보다 오래되었거나 다른 Python 버전으로 컴파일됨), 일반적으로 바이트코드 파일을 디스크에 저장합니다(나중에 다시 컴파일하지 않기 위해). OTOH IronPython은 일반적으로 CLR 코드(디스크에 저장 여부에 따라 다름)로 컴파일하고 Jython을 JVM 코드로 컴파일합니다(디스크에 저장 여부 - 저장하는 경우 .class
그런 다음 이러한 하위 수준 형식은 "인터프리터"라고도 하는 적절한 "가상 머신"에 의해 실행됩니다. 즉, CPython VM, .Net 런타임, Java VM(JVM이라고도 함)이 적절합니다.
따라서 이러한 의미에서(일반적인 구현이 수행하는 작업) Python은 C# 및 Java가 다음과 같은 경우에만 "해석된 언어"입니다. .
초점은 컴파일 프로세스가 얼마나 "무겁고" 느리고 높은 의식인지에 있을 가능성이 높습니다. CPython은 가능한 한 적은 의식으로 가능한 한 빨리, 최대한 가볍게 컴파일하도록 설계되었습니다. 컴파일러는 오류 검사 및 최적화를 거의 수행하지 않으므로 빠르고 적은 양의 메모리에서 실행할 수 있습니다. 대부분의 경우 사용자가 컴파일이 진행 중이라는 사실을 인지할 필요 없이 필요할 때마다 자동으로 투명하게 실행됩니다. Java 및 C#은 일반적으로 오류를 더 철저히 검사하고 더 많은 최적화를 수행하기 위해 컴파일 중에 더 많은 작업을 허용하므로 자동 컴파일을 수행하지 않습니다. 흑백 상황이 아닌 회색조의 연속체이며, 특정 수준에 임계값을 설정하고 해당 수준 이상에서만 "편집"이라고 부르는 것은 완전히 임의적입니다!-)
여기에는 Python 인터프리터가 소스를 컴파일하는 바이트 코드가 포함되어 있습니다. 이 코드는 Python의 가상 머신에 의해 실행됩니다.
Python의 문서 는 다음과 같이 정의를 설명합니다.
파이썬은 컴파일된 언어와 달리 해석된 언어이지만 바이트코드 컴파일러가 있기 때문에 구분이 흐릿할 수 있습니다. 즉, 실행 파일을 명시적으로 생성하지 않고 소스 파일을 직접 실행할 수 있습니다.
해석된 언어라는 것은 없습니다. 인터프리터 또는 컴파일러를 사용하는지 여부는 순전히 구현 의 특성이며 언어와 전혀 관련이 없습니다.
모든 언어는 인터프리터나 컴파일러에 의해 구현될 수 있습니다. 대다수의 언어에는 각 유형의 구현이 하나 이상 있습니다. (예를 들어, C 및 C++용 인터프리터가 있고 JavaScript, PHP, Perl, Python 및 Ruby용 컴파일러가 있습니다.) 게다가 대부분의 현대 언어 구현은 실제로 인터프리터와 컴파일러(또는 여러 컴파일러)를 모두 결합합니다.
언어는 추상적인 수학적 규칙의 집합일 뿐입니다. 인터프리터는 언어에 대한 몇 가지 구체적인 구현 전략 중 하나입니다. 이 둘은 완전히 다른 추상화 수준에서 살고 있습니다. 영어가 유형이 지정된 언어인 경우 "해석된 언어"라는 용어는 유형 오류가 됩니다. 성명은 언어로 정의되지 않을 수 있기 때문에, 그냥 일반 이해가되지 않습니다 (성명도 의미가 있다는 것을 거짓이 잘못된 경우에도 의미 때문에) 단지 허위 아니다 "파이썬은 인터프리터 언어입니다" "해석."
특히, 현재 존재하는 Python 구현을 보면 다음과 같은 구현 전략을 사용하고 있습니다.
당신은 그 목록에 있는 모든 구현들(또 내가 언급하지 않은 tinypy, Shedskin, Psyco 등)에 컴파일러가 있다는 것을 알 수 있을 것입니다. 사실, 내가 아는 한, 현재 순수하게 해석되는 Python 구현은 없으며, 계획된 구현도 없고 구현된 적도 없습니다.
"해석된 언어"라는 용어는 의미가 없을 뿐만 아니라 "해석된 구현이 있는 언어"라는 의미로 해석하더라도 분명히 사실이 아닙니다. 누가 당신에게 그 말을 했는지는 분명히 그가 무슨 말을 하는지 모를 것입니다.
특히, .pyc
파일은 CPython, Stackless Python 또는 Unladen Swallow에서 생성된 캐시된 바이트코드 파일입니다.
.py
파일을 가져올 때 Python 인터프리터에 의해 생성되며 가져온 모듈/프로그램의 "컴파일된 바이트 코드"를 포함합니다. .pyc
.py
파일보다 최신인 경우 import
건너뛸 수 있으므로 시작 속도가 약간 빨라집니다. 그러나 그것은 여전히 해석됩니다.
모듈 로드 속도를 높이기 위해 Python은 컴파일된 모듈 콘텐츠를 .pyc에 캐시합니다.
CPython은 소스 코드를 "바이트 코드"로 컴파일하고 성능상의 이유로 소스 파일에 변경 사항이 있을 때마다 이 바이트 코드를 파일 시스템에 캐시합니다. 컴파일 단계를 건너뛸 수 있기 때문에 Python 모듈을 훨씬 빠르게 로드할 수 있습니다. 소스 파일이 foo.py 인 경우 CPython은 소스 바로 옆에 있는 foo.pyc 파일에 바이트 코드를 캐시합니다.
python3에서 Python의 가져오기 기계는 모든 Python 패키지 디렉토리 내의 단일 디렉토리에서 바이트 코드 캐시 파일을 작성하고 검색하도록 확장되었습니다. 이 디렉토리의 이름은 __pycache__ 입니다.
다음은 모듈이 로드되는 방법을 설명하는 순서도입니다.
자세한 내용은:
참조: PEP3147
ref: "컴파일된" Python 파일
이것은 초보자를 위한 것입니다.
Python은 스크립트를 실행하기 전에 바이트 코드라고 하는 컴파일된 코드로 스크립트를 자동으로 컴파일합니다.
스크립트 실행은 가져오기로 간주되지 않으며 .pyc가 생성되지 않습니다.
당신이 abc.py 실행할 때 그 수입 abc.py 스크립트 파일을 다른 모듈 xyz.py을 경우 XYZ가 수입되기 때문에 예를 들어, xyz.pyc가 생성됩니다,하지만 abc.pyc 파일은 ABC 방송 이후 생성되지 않습니다. py를 가져오지 않습니다.
가져오지 않은 모듈에 대해 .pyc 파일을 생성해야 하는 경우 py_compile
및 compileall
모듈을 사용할 수 있습니다.
py_compile
모듈은 모든 모듈을 수동으로 컴파일할 수 있습니다. 한 가지 방법은 해당 모듈에서 py_compile.compile
함수를 대화식으로 사용하는 것입니다.
>>> import py_compile >>> py_compile.compile('abc.py')
이렇게 하면 .pyc가 abc.py와 같은 위치에 기록됩니다(선택적 매개변수 cfile
덮어쓸 수 있음).
compileall 모듈을 사용하여 디렉토리의 모든 파일을 자동으로 컴파일할 수도 있습니다.
python -m compileall
디렉토리 이름(이 예에서 현재 디렉토리)이 생략되면 모듈은 sys.path
Python(적어도 가장 일반적인 구현)은 원본 소스를 바이트 코드로 컴파일한 다음 가상 머신에서 바이트 코드를 해석하는 패턴을 따릅니다. 이것은 (다시 말하지만, 가장 일반적인 구현은) 순수한 인터프리터도 아니고 순수한 컴파일러도 아니라는 것을 의미합니다.
그러나 이것의 다른 측면은 컴파일 프로세스가 대부분 숨겨져 있다는 것입니다. .pyc 파일은 기본적으로 캐시처럼 취급됩니다. 속도가 빨라지지만 일반적으로 전혀 인식할 필요가 없습니다. 파일 시간/날짜 스탬프를 기반으로 필요할 때 자동으로 무효화하고 다시 로드합니다(소스 코드를 다시 컴파일합니다).
내가 이것과 관련된 문제를 본 유일한 경우는 컴파일된 바이트코드 파일이 어떻게든 미래에 대한 타임스탬프를 얻었을 때였습니다. 더 새것처럼 보였기 때문에 소스 파일은 다시 컴파일되지 않았으므로 어떤 변경 사항을 적용하더라도 무시되었습니다 ...
Python의 *.py 파일은 몇 줄의 코드를 작성하는 텍스트 파일입니다. "python filename.py"를 사용하여 이 파일을 실행하려고 할 때
이 명령은 Python 가상 머신을 호출합니다. Python 가상 머신에는 "컴파일러"와 "인터프리터"의 두 가지 구성 요소가 있습니다. 인터프리터는 *.py 파일의 텍스트를 직접 읽을 수 없으므로 이 텍스트는 먼저 PVM (하드웨어가 아니라 PVM)을 대상으로 하는 바이트 코드로 변환됩니다. PVM은 이 바이트 코드를 실행합니다. *.pyc 파일도 셸이나 다른 파일의 파일에 대한 가져오기 작업을 수행하는 실행의 일부로 생성됩니다.
이 *.pyc 파일이 이미 생성된 경우 다음에 *.py 파일을 실행/실행할 때마다 시스템은 컴파일이 필요하지 않은 *.pyc 파일을 직접 로드합니다(이렇게 하면 프로세서의 일부 기계 주기를 절약할 수 있음).
*.pyc 파일이 생성되면 편집하지 않는 한 *.py 파일이 필요하지 않습니다.
tldr; 파이썬 VM이 실행을 위해 해석하는 소스 코드로부터 변환된 코드입니다.
상향식 이해 : 모든 프로그램의 마지막 단계는 하드웨어/기계에서 프로그램의 명령을 실행/실행하는 것입니다. 실행 전 단계는 다음과 같습니다.
CPU에서 실행/실행
바이트코드를 기계어 코드로 변환하기 .
기계 코드는 변환의 마지막 단계입니다.
CPU에서 실행되는 명령 은 기계어 코드로 제공됩니다. 기계어 코드는 CPU에서 직접 실행할 수 있습니다.
바이트코드 를 기계어로 변환.
소스 코드 를 바이트 코드로 변환.
이제 실제 줄거리 입니다. 이러한 단계를 수행할 때 두 가지 접근 방식이 있습니다. 한 번에 코드를 변환[또는 실행](일명 컴파일 )하고 코드를 한 줄씩 변환[또는 실행](일명 해석 )합니다.
예를 들어 소스 코드를 bytecoe로 컴파일하고 바이트 코드를 기계어로 컴파일하고 기계어를 실행하여 해석할 수 있습니다.
일부 언어 구현은 효율성을 위해 3단계를 건너뜁니다. 즉, 소스 코드를 기계 코드로 컴파일한 다음 실행을 위해 기계 코드를 해석합니다.
일부 구현은 모든 중간 단계를 건너뛰고 실행을 위해 소스 코드를 직접 해석합니다.
현대 언어는 종종 두 가지 해석을 모두 포함합니다 .
예를 들어 JAVA는 소스 코드를 바이트 코드로 컴파일하고[자바 소스가 바이트 코드로 저장되는 방식] 바이트 코드를 기계어로 컴파일하고[JVM을 사용하여] 실행을 위해 기계어 코드를 해석합니다. [따라서 JVM은 OS마다 다르게 구현되지만 JVM이 설치된 다른 OS에서는 동일한 JAVA 소스 코드를 실행할 수 있습니다.]
예를 들어 Python은 소스 코드를 바이트코드로 컴파일하고[보통 .py 소스 코드와 함께 제공되는 .pyc 파일 로 발견됨], bytocde를 머신 코드로 컴파일[PVM과 같은 가상 머신에 의해 수행되며 결과는 실행 파일], 머신 해석 실행을 위한 코드/실행 파일.
언어가 해석되거나 컴파일된다고 말할 수 있는 경우는 언제입니까?
따라서 JAVA와 Python은 해석 언어입니다.
바이트 코드를 기계어로 변환하는 세 번째 단계로 인해 혼동이 발생할 수 있습니다. 종종 이것은 가상 머신 이라는 소프트웨어를 사용하여 수행됩니다. 가상 머신이 머신처럼 작동하기 때문에 혼동이 발생하지만 실제로는 그렇지 않습니다! 가상 머신은 이식성을 위해 도입되었으며 모든 REAL 머신에 VM이 있으면 동일한 소스 코드를 실행할 수 있습니다. 대부분의 VM[세 번째 단계]에서 사용되는 접근 방식은 컴파일이므로 일부 사람들은 이것이 컴파일된 언어 라고 말할 것입니다. VM의 중요성에 대해 우리는 종종 그러한 언어가 컴파일되고 해석 된다고 말합니다.
파이썬 코드는 2단계를 거칩니다. 첫 번째 단계는 코드를 실제로 바이트 코드인 .pyc 파일로 컴파일합니다. 그런 다음 이 .pyc 파일(바이트 코드)은 CPython 인터프리터를 사용하여 해석됩니다. 이 링크를 참조하십시오. 여기서는 코드 컴파일 및 실행 과정을 쉽게 설명합니다.
기계는 영어나 다른 언어를 이해하지 못하고 컴파일(예: C/C++, Java) 또는 해석(예: Ruby, Python)해야 하는 바이트 코드만 이해합니다. .pyc는 다음의 캐시된 버전입니다. 바이트 코드. https://www.geeksforgeeks.org/difference-between-compiled-and-interpreted-language/ 다음은 컴파일된 언어와 해석된 언어의 차이점에 대한 빠른 읽기입니다. TLDR은 해석된 언어이므로 모두 컴파일할 필요가 없습니다. 런타임 이전의 코드이므로 대부분 타이핑 등에 엄격하지 않습니다.
출처 : http:www.stackoverflow.com/questions/2998215/if-python-is-interpreted-what-are-pyc-files
C에서 배열의 크기를 어떻게 결정합니까? (0) | 2023.04.30 |
---|---|
줄 바꿈(줄 연속)은 어떻게 합니까? (0) | 2023.04.30 |
Chrome을 사용하여 XML 대신 JSON을 반환하도록 ASP.NET Web API를 얻으려면 어떻게 해야 합니까? (0) | 2023.04.30 |
"java.lang.OutOfMemoryError: PermGen 공간" 오류 처리 (0) | 2023.04.30 |
루프에서 개체를 제거할 때 ConcurrentModificationException을 방지하면서 컬렉션을 반복합니다. (0) | 2023.04.30 |