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.
–
JobFeb 26 '12 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.
–
gbjbaanbFeb 26 '12 at 12:55

2

@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 FSMar 5 '12 at 7:06

4 Answers
4

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

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

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.
–
tdammersFeb 26 '12 at 8:52

1

I don't see how C/C++ doesn't specify what the linker needs; after all, there are a lot of C and C++ programs out there.
–
Billy ONealFeb 26 '12 at 9:26

1

@Billy: I expanded on that in my answer. Short version is that makefiles aren't actually part of C or C++.
–
Mike DeSimoneFeb 26 '12 at 13:01

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 FSMar 5 '12 at 7:13

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.

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.)
–
Jörg W MittagFeb 26 '12 at 4:48

2

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).
–
Jörg W MittagFeb 26 '12 at 4:56

6

@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.
–
tdammersFeb 26 '12 at 8:49

1

@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.
–
Winston EwertFeb 26 '12 at 15:48

1

Its also worth pointing out that there is a PHP compiler called HipHop developed by facebook. However, it works by not including features like eval.
–
Winston EwertFeb 26 '12 at 15:51

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.