Python이 해석되는 경우 .pyc 파일은 무엇입니까?

Python이 해석되는 경우 .pyc 파일은 무엇입니까?

---

나는 파이썬이 해석 언어라는 것을 이해하도록 주어졌습니다. 그러나 파이썬 소스 코드를 보면 .pycWindows가 "컴파일 된 파이썬 파일"로 식별하는 파일이 보입니다 . 이들은 어디로 들어 갑니까?

---

여기에는 Python 인터프리터가 소스를 컴파일하는 바이트 코드가 포함되어 있습니다 . 이 코드는 Python의 가상 머신에서 실행됩니다.

Python의 문서는 다음과 같은 정의를 설명합니다.

파이썬은 컴파일 된 언어와는 달리 해석 된 언어이지만 바이트 코드 컴파일러의 존재로 인해 구별이 모호 할 수 있습니다. 즉, 실행 파일을 명시 적으로 생성하지 않고도 소스 파일을 직접 실행할 수 있습니다.

---

나는 파이썬이 해석 언어라는 것을 이해하기 위해 주어졌습니다.

이 인기있는 밈은 부정확하거나 오히려 (자연적인) 언어 수준에 대한 오해를 바탕으로 구성되었습니다. 비슷한 실수는 "성경은 하드 커버 책입니다"라고 말하는 것입니다. 그 직유를 설명하겠습니다 ...

"성경"은 책의 한 부류 라는 의미에서 "책"입니다 . "성경 사본"으로 식별 된 책은 기본적인 공통점이 있어야합니다 (내용조차도 다른 언어, 허용 가능한 번역, 각주 수준 및 기타 주석이 다를 수 있음). 제본 종류, 제본 색상, 인쇄에 사용 된 글꼴, 삽화가있는 경우, 넓은 쓰기 가능 여백 여부, 기본 제공 책갈피의 수 및 종류와 같이 기본으로 간주 되지 않는 수많은 측면에서 완벽하게 다를 수 있습니다. , 등등.

성경 의 전형적인 인쇄본이 실제로 양장본 제본에있을 가능성이 매우 높습니다. 결국 일반적으로 반복해서 읽고, 여러 장소에 책갈피를 추가하고, 주어진 장과 절에 대한 포인터를 찾아서 엄지 손가락을 치켜 세워야하는 책입니다. , 등, 좋은 하드 커버 제본은 그러한 사용에서 주어진 사본을 더 오래 지속시킬 수 있습니다. 그러나 이것은 주어진 실제 책 개체가 성경의 사본인지 여부를 결정하는 데 사용할 수없는 평범한 (실용적인) 문제입니다. 페이퍼 백 인쇄는 완벽하게 가능합니다!

비슷하게, 파이썬은 몇 가지 근본적인 측면 (구문, 명시 적으로 다른 부분이 허용되는 부분을 제외한 대부분의 의미)에서 모두 유사해야하지만 완전히 허용되는 언어 구현 클래스를 정의한다는 의미에서 "언어"입니다. 제공된 소스 파일을 처리하는 방법, 소스를 하위 수준 형식으로 컴파일하는지 여부 (그렇다면 어떤 형식으로 컴파일하는지) 및 저장 여부를 포함하여 거의 모든 "구현"세부 사항이 다릅니다. 컴파일 된 양식, 디스크 또는 다른 곳으로), 양식을 실행하는 방법 등.

고전적인 구현 인 CPython은 종종 간단히 "Python"이라고 불립니다. 그러나 Microsoft의 IronPython (CLR 코드로 컴파일, 즉 ".NET"), Jython과 나란히있는 여러 프로덕션 품질 구현 중 하나 일뿐입니다. (JVM 코드로 컴파일되는), PyPy (Python 자체로 작성되었으며 "just-in-time"생성 기계어를 포함하여 매우 다양한 "백엔드"형식으로 컴파일 할 수 있음). 피상적으로 다른 많은 책 개체가 모두 성경 (== "성경 사본")이 될 수있는 것처럼 그것들은 모두 파이썬 (== "파이썬 언어의 구현")입니다.

특히 CPython에 관심이있는 경우 소스 파일을 Python 고유의 하위 수준 형식 ( "바이트 코드"라고 함)으로 컴파일하고 필요할 때 자동으로 컴파일합니다 (소스 파일에 해당하는 바이트 코드 파일이 없을 때 또는 바이트 코드 파일이 소스보다 오래되었거나 다른 Python 버전으로 컴파일되었습니다), 일반적으로 바이트 코드 파일을 디스크에 저장합니다 (나중에 다시 컴파일하지 않기 위해). OTOH IronPython은 일반적으로 CLR 코드 (디스크에 저장하거나 저장하지 않음)로 컴파일하고 Jython을 JVM 코드 (디스크에 저장하거나 저장하지 않음- .class저장 하면 확장 을 사용함)로 컴파일합니다 .

그런 다음 이러한 하위 수준 형식은 CPython VM, .Net 런타임, Java VM (일명 JVM) 등 "해석기"라고도하는 적절한 "가상 머신"에 의해 실행됩니다.

따라서 이러한 의미에서 (일반적인 구현이 수행하는 작업) Python은 C # 및 Java가 다음과 같은 경우에만 "해석 된 언어"입니다. 모두가 먼저 바이트 코드를 생성 한 다음 VM / 인터프리터를 통해 실행하는 일반적인 구현 전략을 가지고 있습니다. .

더 많이 초점은 컴파일 프로세스가 얼마나 "무겁고"느리고 높은 의식인지에 있습니다. CPython은 가능한 한 적은 의식으로 가능한 한 가볍고 가능한 한 빨리 컴파일하도록 설계되었습니다. 컴파일러는 오류 검사 및 최적화를 거의 수행하지 않으므로 적은 양의 메모리로 빠르게 실행할 수 있습니다. 대부분의 경우 컴파일이 진행되고 있다는 사실을 사용자가 인식 할 필요없이 필요할 때마다 자동으로 투명하게 실행됩니다. Java 및 C #은 일반적으로 오류를보다 철저히 확인하고 더 많은 최적화를 수행하기 위해 컴파일 중에 더 많은 작업을 허용하므로 자동 컴파일을 수행하지 않습니다. 흑백 상황이 아니라 회색조의 연속체입니다.

---

통역 언어 같은 것은 없습니다. 인터프리터 또는 컴파일러가 사용되는지 여부는 순전히 구현 의 특성이며 언어와는 전혀 관련이 없습니다.

모든 언어는 인터프리터 또는 컴파일러에 의해 구현 될 수 있습니다. 대부분의 언어에는 각 유형에 대해 하나 이상의 구현이 있습니다. (예를 들어, C 및 C ++ 용 인터프리터가 있고 JavaScript, PHP, Perl, Python 및 Ruby 용 컴파일러가 있습니다.) 게다가 대부분의 최신 언어 구현은 실제로 인터프리터와 컴파일러 (또는 여러 컴파일러)를 결합합니다.

언어는 추상적 인 수학적 규칙의 집합 일뿐입니다. 인터프리터는 언어에 대한 몇 가지 구체적인 구현 전략 중 하나입니다. 이 두 가지는 완전히 다른 추상화 수준에서 살고 있습니다. 영어가 입력 된 언어 인 경우 "해석 된 언어"라는 용어는 유형 오류입니다. 성명은, 그냥 일반하지 않습니다 (성명도 의미가 있다는 것을 거짓이 잘못된 경우에도 의미 때문에) 단지 허위 아니다 "파이썬은 인터프리터 언어는" 감각을 언어가 수 있기 때문에, 결코 정의되지 "해석."

특히 현재 기존 Python 구현을 살펴보면 사용중인 구현 전략은 다음과 같습니다.

• IronPython : DLR이 CIL 바이트 코드로 컴파일하는 DLR 트리로 컴파일합니다. CIL 바이트 코드에 발생하는 일은 실행중인 CLI VES에 따라 다르지만 Microsoft .NET, GNU Portable.NET 및 Novell Mono는 결국이를 원시 기계 코드로 컴파일합니다.
• Jython : 핫 코드 경로를 식별 할 때까지 Python 소스 코드를 해석 한 다음 JVML 바이트 코드로 컴파일합니다. JVML 바이트 코드에 발생하는 일은 실행중인 JVM에 따라 다릅니다. Maxine은 핫 코드 경로를 식별 할 때까지 최적화되지 않은 네이티브 코드로 직접 컴파일 한 다음 최적화 된 네이티브 코드로 다시 컴파일합니다. HotSpot은 먼저 JVML 바이트 코드를 해석 한 다음 결국 최적화 된 기계 코드에 대한 핫 코드 경로를 컴파일합니다.
• PyPy : PyPy 바이트 코드로 컴파일 한 다음 실행중인 플랫폼에 따라 네이티브 코드, JVML 바이트 코드 또는 CIL 바이트 코드로 컴파일되는 핫 코드 경로를 식별 할 때까지 PyPy VM에 의해 해석됩니다.
• CPython : CPython 바이트 코드로 컴파일 한 다음 해석합니다.
• Stackless Python : CPython 바이트 코드로 컴파일 한 다음 해석합니다.
• Unladen Swallow : CPython 바이트 코드로 컴파일 한 다음 핫 코드 경로를 식별 할 때까지 해석 한 다음 LLVM 컴파일러가 원시 기계 코드로 컴파일하는 LLVM IR로 컴파일합니다.
• Cython : Python 코드를 이식 가능한 C 코드로 컴파일 한 다음 표준 C 컴파일러로 컴파일합니다.
• Nuitka : Python 코드를 기계 종속 C ++ 코드로 컴파일 한 다음 표준 C 컴파일러로 컴파일합니다.

해당 목록의 모든 구현 (그리고 내가 언급하지 않은 tinypy, Shedskin 또는 Psyco 등)에는 컴파일러가 있다는 것을 알 수 있습니다. 사실, 내가 아는 한, 현재 순전히 해석되는 파이썬 구현은 없으며, 그러한 구현이 계획되어 있지 않으며 그러한 구현도 없었습니다.

"통역 된 언어"라는 용어는 의미가 없을뿐만 아니라 "통역 된 구현 언어"를 의미하는 것으로 해석하더라도 분명히 사실이 아닙니다. 누가 그렇게 말 했든 그가 무슨 말을하는지 분명히 알지 못합니다.

특히 .pyc보고있는 파일은 CPython, Stackless Python 또는 Unladen Swallow에서 생성 한 캐시 된 바이트 코드 파일입니다.

---

These are created by the Python interpreter when a .py file is imported, and they contain the "compiled bytecode" of the imported module/program, the idea being that the "translation" from source code to bytecode (which only needs to be done once) can be skipped on subsequent imports if the .pyc is newer than the corresponding .py file, thus speeding startup a little. But it's still interpreted.

---

To speed up loading modules, Python caches the compiled content of modules in .pyc.

CPython compiles its source code into "byte code", and for performance reasons, it caches this byte code on the file system whenever the source file has changes. This makes loading of Python modules much faster because the compilation phase can be bypassed. When your source file is foo.py , CPython caches the byte code in a foo.pyc file right next to the source.

In python3, Python's import machinery is extended to write and search for byte code cache files in a single directory inside every Python package directory. This directory will be called __pycache__ .

Here is a flow chart describing how modules are loaded:

For more information:

ref:PEP3147
ref:“Compiled” Python files

---

THIS IS FOR BEGINNERS,

Python automatically compiles your script to compiled code, so called byte code, before running it.

Running a script is not considered an import and no .pyc will be created.

For example, if you have a script file abc.py that imports another module xyz.py, when you run abc.py, xyz.pyc will be created since xyz is imported, but no abc.pyc file will be created since abc.py isn’t being imported.

If you need to create a .pyc file for a module that is not imported, you can use the py_compile and compileall modules.

The py_compile module can manually compile any module. One way is to use the py_compile.compile function in that module interactively:

>>> import py_compile
>>> py_compile.compile('abc.py')

This will write the .pyc to the same location as abc.py (you can override that with the optional parameter cfile).

You can also automatically compile all files in a directory or directories using the compileall module.

python -m compileall

If the directory name (the current directory in this example) is omitted, the module compiles everything found on sys.path

---

Python (at least the most common implementation of it) follows a pattern of compiling the original source to byte codes, then interpreting the byte codes on a virtual machine. This means (again, the most common implementation) is neither a pure interpreter nor a pure compiler.

The other side of this is, however, that the compilation process is mostly hidden -- the .pyc files are basically treated like a cache; they speed things up, but you normally don't have to be aware of them at all. It automatically invalidates and re-loads them (re-compiles the source code) when necessary based on file time/date stamps.

About the only time I've seen a problem with this was when a compiled bytecode file somehow got a timestamp well into the future, which meant it always looked newer than the source file. Since it looked newer, the source file was never recompiled, so no matter what changes you made, they were ignored...

---

Python's *.py file is just a text file in which you write some lines of code. When you try to execute this file using say "python filename.py"

This command invokes Python Virtual Machine. Python Virtual Machine has 2 components: "compiler" and "interpreter". Interpreter cannot directly read the text in *.py file, so this text is first converted into a byte code which is targeted to the PVM (not hardware but PVM). PVM executes this byte code. *.pyc file is also generated, as part of running it which performs your import operation on file in shell or in some other file.

If this *.pyc file is already generated then every next time you run/execute your *.py file, system directly loads your *.pyc file which won't need any compilation(This will save you some machine cycles of processor).

Once the *.pyc file is generated, there is no need of *.py file, unless you edit it.

---

Python code goes through 2 stages. First step compiles the code into .pyc files which is actually a bytecode. Then this .pyc file(bytecode) is interpreted using CPython interpreter. Please refer to this link. Here process of code compilation and execution is explained in easy terms.

참고URL : https://stackoverflow.com/questions/2998215/if-python-is-interpreted-what-are-pyc-files