I've been given to understand that Python is an interpreted language...
However, when I look at my Python source code I see .pyc files, which Windows identifies as "Compiled Python Files".

Where do these come in?


They contain byte code, which is what the Python interpreter compiles the source to. This code is then executed by Python's virtual machine.

Python's documentation explains the definition like this:


| improve this answer | |
  • 10
    Interesting, thanks. So is Python considered a purely interpreted language? – froadie Jun 8 '10 at 14:37
  • 194
    @froadie: a language is not "interpreted" or "compiled" as such. A specific implementation can be an interpreter or a compiler (or a hybrid or a JIT compiler). – Joachim Sauer Jun 8 '10 at 14:41
  • 30
    One test of 'compiled': is it compiled to actual machine instructions? Python bytecode are not machine instructions, and neither are Java 'JVM' instructions, so neither of these languages are compiled by that definition. But both 'compiled' to an intermediate 'abstract machine' code, and both are far, faster than running the program by more or less directly interpreting the source code (which is what old-school BASIC does). – greggo Apr 5 '13 at 18:11
  • 20
    To be pedantic, 'compiled' means 'translated'. Python is then compiled to a bytecode. AFAIK, only Bash is really interpreted , all other popular "interpreted" languages are all compiled to a bytecode. – bfontaine Aug 6 '14 at 13:42
  • 13
    Actually, they are machine instructions, just not native machine instructions for the host's physical CPU. Hence why we call it a VM ? Like Esperanto for assembly language really. Nowadays we even have native code for fictional (but still emulated) CPU's (Mojang's effort to get the kiddies interested). Rexx was (or could be) truly interpreted, and BAT and CMD (and DCL) are interpreted. – mckenzm Dec 13 '14 at 10:38


This popular meme is incorrect, or, rather, constructed upon a misunderstanding of (natural) language levels: a similar mistake would be to say "the Bible is a hardcover book". Let me explain that simile...

"The Bible" is "a book" in the sense of being a class of (actual, physical objects identified as) books; the books identified as "copies of the Bible" are supposed to have something fundamental in common (the contents, although even those can be in different languages, with different acceptable translations, levels of footnotes and other annotations) -- however, those books are perfectly well allowed to differ in a myriad of aspects that are not considered fundamental -- kind of binding, color of binding, font(s) used in the printing, illustrations if any, wide writable margins or not, numbers and kinds of builtin bookmarks, and so on, and so forth.

It's quite possible that a typical printing of the Bible would indeed be in hardcover binding -- after all, it's a book that's typically meant to be read over and over, bookmarked at several places, thumbed through looking for given chapter-and-verse pointers, etc, etc, and a good hardcover binding can make a given copy last longer under such use. However, these are mundane (practical) issues that cannot be used to determine whether a given actual book object is a copy of the Bible or not: paperback printings are perfectly possible!

Similarly, Python is "a language" in the sense of defining a class of language implementations which must all be similar in some fundamental respects (syntax, most semantics except those parts of those where they're explicitly allowed to differ) but are fully allowed to differ in just about every "implementation" detail -- including how they deal with the source files they're given, whether they compile the sources to some lower level forms (and, if so, which form -- and whether they save such compiled forms, to disk or elsewhere), how they execute said forms, and so forth.

The classical implementation, CPython, is often called just "Python" for short -- but it's just one of several production-quality implementations, side by side with Microsoft's IronPython (which compiles to CLR codes, i.e., ".NET"), Jython (which compiles to JVM codes), PyPy (which is written in Python itself and can compile to a huge variety of "back-end" forms including "just-in-time" generated machine language). They're all Python (=="implementations of the Python language") just like many superficially different book objects can all be Bibles (=="copies of The Bible").

If you're interested in CPython specifically: it compiles the source files into a Python-specific lower-level form (known as "bytecode"), does so automatically when needed (when there is no bytecode file corresponding to a source file, or the bytecode file is older than the source or compiled by a different Python version), usually saves the bytecode files to disk (to avoid recompiling them in the future). OTOH IronPython will typically compile to CLR codes (saving them to disk or not, depending) and Jython to JVM codes (saving them to disk or not -- it will use the .class extension if it does save them).

These lower level forms are then executed by appropriate "virtual machines" also known as "interpreters" -- the CPython VM, the .Net runtime, the Java VM (aka JVM), as appropriate.

So, in this sense (what do typical implementations do), Python is an "interpreted language" if and only if C# and Java are: all of them have a typical implementation strategy of producing bytecode first, then executing it via a VM/interpreter.

More likely the focus is on how "heavy", slow, and high-ceremony the compilation process is. CPython is designed to compile as fast as possible, as lightweight as possible, with as little ceremony as feasible -- the compiler does very little error checking and optimization, so it can run fast and in small amounts of memory, which in turns lets it be run automatically and transparently whenever needed, without the user even needing to be aware that there is a compilation going on, most of the time. Java and C# typically accept more work during compilation (and therefore don't perform automatic compilation) in order to check errors more thoroughly and perform more optimizations. It's a continuum of gray scales, not a black or white situation, and it would be utterly arbitrary to put a threshold at some given level and say that only above that level you call it "compilation"!-)

| improve this answer | |
  • 2
    Beautiful answer. Just a small correction to the last paragraph: Python is designed to compile as fast as possible (etc.). This time it really is the language, with its lack of static type system and stuff. When people talk about "interpreted" languages, they usually mean "dynamic" languages. – Elazar Dec 14 '15 at 21:58
  • 1
    @Elazar, actually, other implementations of Python, such as PyPy, which are in no hurry to compile, manage to do the more thorough analysis required by the lack of static typing and produce just-in-time compilation to machine code (thus speeding up long-running programs by many times). – Alex Martelli Dec 15 '15 at 1:42
  • Where does Cython fit in here? Would you consider it a different language or is it a Python implementation? Also, is this meme of "interpreted" vs compiled perhaps just a terminology confusion because Python's VM is often referred to as its "interpreter"? It would be just as valid to call the JVM or the .NET runtime interpreters. They both mostly interpret bytecode into JIT machine code (with some caching optimization exceptions) – Davos Apr 6 '18 at 12:28

There is no such thing as an interpreted language. Whether an interpreter or a compiler is used is purely a trait of the implementation and has absolutely nothing whatsoever to do with the language.

Every language can be implemented by either an interpreter or a compiler. The vast majority of languages have at least one implementation of each type. (For example, there are interpreters for C and C++ and there are compilers for JavaScript, PHP, Perl, Python and Ruby.) Besides, the majority of modern language implementations actually combine both an interpreter and a compiler (or even multiple compilers).

A language is just a set of abstract mathematical rules. An interpreter is one of several concrete implementation strategies for a language. Those two live on completely different abstraction levels. If English were a typed language, the term "interpreted language" would be a type error. The statement "Python is an interpreted language" is not just false (because being false would imply that the statement even makes sense, even if it is wrong), it just plain doesn't make sense, because a language can never be defined as "interpreted."

In particular, if you look at the currently existing Python implementations, these are the implementation strategies they are using:

  • IronPython: compiles to DLR trees which the DLR then compiles to CIL bytecode. What happens to the CIL bytecode depends upon which CLI VES you are running on, but Microsoft .NET, GNU Portable.NET and Novell Mono will eventually compile it to native machine code.
  • Jython: interprets Python sourcecode until it identifies the hot code paths, which it then compiles to JVML bytecode. What happens to the JVML bytecode depends upon which JVM you are running on. Maxine will directly compile it to un-optimized native code until it identifies the hot code paths, which it then recompiles to optimized native code. HotSpot will first interpret the JVML bytecode and then eventually compile the hot code paths to optimized machine code.
  • PyPy: compiles to PyPy bytecode, which then gets interpreted by the PyPy VM until it identifies the hot code paths which it then compiles into native code, JVML bytecode or CIL bytecode depending on which platform you are running on.
  • CPython: compiles to CPython bytecode which it then interprets.
  • Stackless Python: compiles to CPython bytecode which it then interprets.
  • Unladen Swallow: compiles to CPython bytecode which it then interprets until it identifies the hot code paths which it then compiles to LLVM IR which the LLVM compiler then compiles to native machine code.
  • Cython: compiles Python code to portable C code, which is then compiled with a standard C compiler
  • Nuitka: compiles Python code to machine-dependent C++ code, which is then compiled with a standard C compiler

You might notice that every single one of the implementations in that list (plus some others I didn't mention, like tinypy, Shedskin or Psyco) has a compiler. In fact, as far as I know, there is currently no Python implementation which is purely interpreted, there is no such implementation planned and there never has been such an implementation.

Not only does the term "interpreted language" not make sense, even if you interpret it as meaning "language with interpreted implementation", it is clearly not true. Whoever told you that, obviously doesn't know what he is talking about.

In particular, the .pyc files you are seeing are cached bytecode files produced by CPython, Stackless Python or Unladen Swallow.

| improve this answer | |
  • 5
    Old-school basic such as MSBASIC had no intermediate form. The program was interpreted directly from the source form (or near source, a form in which keywords were represented by 1-byte tokens, and line #'s by 2-byte binary ints, but the rest was just ASCII). So in fact a 'goto' would take different amounts of time depending on how many source lines it had to search through looking for the matching destination. Expressions like a*b-2*cos(x) were effectively re-parsed every time they were executed. – greggo Apr 5 '13 at 18:22
  • 4
    @greggo: And if you want to go even more old-school, the original version of BASIC was a native code compiler. This should prove how ridiculous the notion of a "compiled" or "interpreted" language is. – Jörg W Mittag Apr 6 '13 at 7:56
  • Thanks for explaining how the various python compilers/interpreters behave. I wonder if there are good Python compilers that generate efficient C or JavaScript yet. It seems very doable, maybe not for mass consumption, but for a reasonable subset of Python at least. Also I wonder what Cython is. – personal_cloud Sep 29 '17 at 15:56
  • Cython was mentioned in SciPy 2009, but I can forgive you for not knowing about it back in 2010 (here I am in 2017 only just now learning about it). Still we ought to find a JavaScript example... Jython makes no sense to me (wasn't Java already dead by 2009? Well hmm, maybe not... C++ boost wasn't so good back then) – personal_cloud Sep 29 '17 at 16:08
  • 1
    @personal_cloud: I don't quite follow your comment. Yes, of course, I know about Cython, but what does that have to do with anything? It's not an implementation of Python, it is a completely different language. Also, it's really not hard to find a JavaScript example, in fact, all currently existing mainstream JavaScript implementations have compilers. Lastly, Jython is an implementation of Python just like any other implementation of Python. And it is an implementation of a language on the Java platform just like any other language implementation on the Java platform. – Jörg W Mittag Sep 30 '17 at 2:06

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.

| improve this answer | |
  • 10
    True. Except many core Python libraries are written in C. So parts of python run interpreted, part run in C. You can do the same to your own performance sensitive bits of code. – bwawok Jun 8 '10 at 14:43

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



Here is a flow chart describing how modules are loaded:

enter image description here

For more information:

ref:“Compiled” Python files

| improve this answer | |


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).


python -m compileall

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

| improve this answer | |
  • 6
    and what is the benefit of compiling to get the abc.py? – Saher Ahwal Feb 14 '17 at 8:06
  • @SaherAhwal One benefit I can think of is syntax checking. – Yi Bao Feb 12 at 22:58

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...

| improve this answer | |

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.

| improve this answer | |

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.

| improve this answer | |
