Why doesn't Python need a compiler?

Question

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.

Answer 1

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

Answer 2

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.

Answer 3

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.

Answer 4

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.

Answer 5

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.