Just wondering (now that I've started with C++ which needs a compiler) why Python doesn't need a compiler?

I just enter the code, save it as an exec, and run it. In C++ I have to make builds and all of that other fun stuff.

  • 4
    Python is just a language with many implementations. Iron Python is compiled in the same way C# and C++ is compiled, and there may be other implementations like it.
    – Job
    Commented Feb 26, 2012 at 1:48
  • 1
    C# and C++ are not compiled the same way - though you could argue that they both end up as machine instructions eventually, but if you do then you can say BASIC is compiled the same way too.
    – gbjbaanb
    Commented Feb 26, 2012 at 12:55
  • 7
    @gbjbaanb but then again English is not compiled and the semantic analysis of one sentence might yield two equally valid results and the above could be read as "iron python is compiled just as C# and C++ is compiled"
    – Rune FS
    Commented Mar 5, 2012 at 7:06
  • What platform / software are you using to write your Python code? If you write a .py file, it is not an executable. It is still a source code file. From the command line you are using the python command to interpret the .py file or if you use IDLE or Eclipse the IDE does it for you. Commented Jul 26, 2016 at 16:04

5 Answers 5


Python has a compiler! You just don't notice it because it runs automatically. You can tell it's there, though: look at the .pyc (or .pyo if you have the optimizer turned on) files that are generated for modules that you import.

Also, it does not compile to the native machine's code. Instead, it compiles to a byte code that is used by a virtual machine. The virtual machine is itself a compiled program. This is very similar to how Java works; so similar, in fact, that there is a Python variant (Jython) that compiles to the Java Virtual Machine's byte code instead! There's also IronPython, which compiles to Microsoft's CLR (used by .NET). (The normal Python byte code compiler is sometimes called CPython to disambiguate it from these alternatives.)

C++ needs to expose its compilation process because the language itself is incomplete; it does not specify everything the linker needs to know to build your program, nor can it specify compile options portably (some compilers let you use #pragma, but that's not standard). So you have to do the rest of the work with makefiles and possibly auto hell (autoconf/automake/libtool). This is really just a holdover from how C did it. And C did it that way because it made the compiler simple, which is one main reason it is so popular (anyone could crank out a simple C compiler in the 80's).

Some things that can affect the compiler's or linker's operation but are not specified within C or C++'s syntax:

  • dependency resolution
  • external library requirements (including dependency order)
  • optimizer level
  • warning settings
  • language specification version
  • linker mappings (which section goes where in the final program)
  • target architecture

Some of these can be detected, but they can't be specified; e.g. I can detect which C++ is in use with __cplusplus, but I can't specify that C++98 is the one used for my code within the code itself; I have to pass it as a flag to the compiler in the Makefile, or make a setting in a dialog.

While you might think that a "dependency resolution" system exists in the compiler, automatically generating dependency records, these records only say which header files a given source file uses. They cannot indicate what additional source code modules are required to link into an executable program, because there is no standard way in C or C++ to indicate that a given header file is the interface definition for another source code module as opposed to just a bunch of lines you want to show up in multiple places so you don't repeat yourself. There are traditions in file naming conventions, but these are not known or enforced by the compiler and linker.

Several of these can be set using #pragma, but this is non-standard, and I was speaking of the standard. All of these things could be specified by a standard, but have not been in the interest of backward compatibility. The prevailing wisdom is that makefiles and IDEs aren't broke, so don't fix them.

Python handles all this in the language. For example, import specifies an explicit module dependency, implies the dependency tree, and modules are not split into header and source files (i.e. interface and implementation).

  • 4
    The C implementation of Python is CPython, Cython is something different. Commented Feb 26, 2012 at 2:53
  • 5
    Other reasons why C compiled to machine code were that it was intended to be little more than a glorified assembler, because bytecode interpreters were technically unfeasible on the hardware they had, and because one of the most important tasks was writing an OS kernel.
    – tdammers
    Commented Feb 26, 2012 at 8:52
  • 2
    @BillyONeal with the one big exception that in c/c++ you as a programmer has to do stuff in a certain way (either makefiles or dump every thing into the same blob) in python you just do your work and the compiler together with the VM takes care of the rest
    – Rune FS
    Commented Mar 5, 2012 at 7:13
  • 3
    "C++ needs to expose its compilation process because the language itself is incomplete" Er, what?? Commented Jul 31, 2015 at 22:27
  • 3
    You read the part right after that, right? "it does not specify everything the linker needs to know to build your program, nor can it specify compile options portably." You can't just build any C++ file by feeding it to a compiler; frequently you have to provide metadata like compile flags, include paths, etc. This metadata isn't specified by the standard and is not portable, which is why we have to drag in other things like make, cmake, Visual Studio, or whatever to finish the job. So the standard has to call out some things as in the compilation unit and others as program-wide. Commented Aug 3, 2015 at 13:49

Python is an interpreted language. This means that there is software on your computer that reads the Python code, and sends the "instructions" to the machine. The Wikipedia article on interpreted languages might be of interest.

When a language like C++ (a compiled language) is compiled, it means that it is converted into machine code to be read directly by the hardware when executed. The Wikipedia article on compiled languages might provide an interesting contrast.

  • 26
    There is no such thing as an interpreted or a compiled language. A language is an abstract set of mathematical rules. A language isn't compiled or interpreted. A language just is. Compilation and interpretation are traits of the compiler or interpreter (duh!), not the language. Every language can be implemented with a compiler and every language can be implemented with an interpreter. Most languages have both compiled and interpreted implementations. There are interpreters for C++ and there are compilers for Python. (In fact, all currently existing Python implementations have compilers.) Commented Feb 26, 2012 at 4:48
  • 4
    The majority of modern high-performance language implementations combine both an interpreter and a compiler (or even several compilers) for maximum performance. Actually, it is impossible to run any program without an interpreter. After all, a compiler is just a program which translates a program from one language to another language. But at some point you have to actually run the program, which is done by an interpreter (which may or may not be implemented in silicon). Commented Feb 26, 2012 at 4:56
  • 10
    @JörgWMittag: You are technically right. However, most languages were designed for an interpreted context or for full compilation. Writing an interpreter for GW BASIC or Common Lisp is much easier than writing one for, say, C++ or C#; Python loses many of its selling points without the interactive environment; writing a compiler for PHP is pretty damn hard, and probably horribly inefficient, as the compiled executable would have to contain the entire PHP interpreter, due to eval() and similar constructs - one could argue that such a compiler would be cheating.
    – tdammers
    Commented Feb 26, 2012 at 8:49
  • 2
    @tdammers, yes. We can reasonably use "compiled language" to mean "language usually compiled." But that misses the point that PHP, Java, Python, Lua, and C# are all implemented as compilers to bytecode. All of these languages have also had JIT's implemented for them. So really, you can't really call some of these languages compiled and some interpreted because they've got the same implementation strategy. Commented Feb 26, 2012 at 15:48
  • 2
    @BillyONeal, not true at least for python. You can distribute python bytecode and run that without the source. But is true that you can't distribute python without a compiler. Commented Feb 26, 2012 at 21:20

Not all compiled languages have an in-your-face edit-compile-link-run cycle.

What you're running into is a feature/limitation of C++ (or at least C++ implementations).

To do anything, you must store your code into files, and build a monolithic image by a process called linking.

In particular, it's this monolithic linking process which is mistaken for the distinction between compiling and interpreting.

Some languages do all this stuff much more dynamically, by eliminating the clumsy monolithic linking step, not by eliminating compiling to machine code. Source is still compiled to object files, but these are loaded into a run-time image, rather than linked into a monolithic executable.

You say "reload this module", and it loads the source and interprets it, or compiles it, depending on some mode switch.

Linux kernel programming has some of this flavor even though you're working in C. You can recompile a module and load and unload it. Of course, you're still aware that you're producing some executable thing, and it's managed by a complex build system, with still some manual steps. But the fact is that in the end you can unload and re-load just that small module and not have to restart the whole kernel.

Some languages have an even more fine grained modularization than this, and the building and loading is done from within their run-time, so it is more seamless.


what a diversion from the initial question... A point not mentioned is that the source of a python program is what you use and distribute, from a user perspective it IS the program. We tend to simplify things into categories that are not well defined.

Compiled programs are usually considered to be stand alone files of machine code. (admittedly often containing links to dynamic link libraries associated with specific operating systems). This said... there are variation of most programing language that could be described as compiled or interpreted.

Python does not need a compiler because it relies on an application (called an interpreter) that compiles and runs the code without storing the machine code being created in a form that you can easily access or distribute.


All programming languages require translation from human concepts into a target machine code. Even assembly language must be translated into machine code. That translation usually takes place in the following phases:

Phase 1: Analysis and translation (parsing) into an intermediate code. Phase 2: Translation of the intermediate code into target machine code with place holders for external references. Phase 3: Resolution of the external references and packaging into a machine executable program.

This translation is often referred to as pre-compiling and "Just in time" (JIT) or run-time-compiling.

Languages such as C, C++, COBOL, Fortran, Pascal (not all) and Assembly are precompiled languages that can be executed directly by the opertating system without need of an interpreter.

Languages like Java, BASIC, C# and Python are interpreted. They all use that intermediate code created in Phase 1, but will sometimes differ in how they translate it into machine code. The simplest forms use that intermediate code to execute machine code routines that do the expected work. Others will compile the intermediate code down to machine code and do the external dependency fixing during runtime. Once compiled it can be immediately executed. As well the machine code is stored in a cache of previously-compiled reusable machine code that can later be reused if the function is needed again later. If a function has already been cached, the interpreter does not need to compile it again.

Most modern high level languages fall into the interpreted (with JIT) category. It is mostly the older languages like C & C++ that is precompiled.

Not the answer you're looking for? Browse other questions tagged or ask your own question.