Python interpreter

walden, system, systems, walden systems, accordion, backup, back up,back, up, ransom, ware, ransomware, data, recovery, critical, protection, remote, virtual, cloud, computing, desktop, ciel, cielview, view, vm, machine, vdi, infrastructure, server, paas, saas, platform, service, software, serverless, thin, client, workspace, private, public, iaas, cloud, terminal, ssh, developer, java, objective, c, c++, c#, plus, sharp, php, Excel, sql, windows, os, operating, system, o.s., powershell, power, shell, javascript, js, python, py, networks, faq, perl, pl, programming, script, scripting, program, programer, code, coding, example, devel, stored, procedure, sp, macro, switch, hub, router, ios, net, .net, interpreter socket, nas, network storage, virus, security



     Python is an interpreted language as opposed to a compiled language. What this means is that the instructions are not directly executed by the machine, but instead read and executed by some other program. The upside of interpreted languages are that it is easier to to implement, can use dynamic data types and there is no need to compile the code for a particular cpu. Python uses an interpreter as opposed to Java, which uses a Java Virtual Machine. A virtual machine is a virtual environment with a specific set of atomic, well defined instructions that are supported independently of any specific language and it is generally thought of as a sandbox. The VM is similar to an instruction set of a specific CPU and tends to work at a more fundamental level with very basic building blocks of such instructions (or byte codes) that are independent of the next. An instruction executes deterministically based only on the current state of the virtual machine and does not depend on information elsewhere in the instruction stream at that point in time.

     An interpreter on the other hand is tailored to parse a stream of some syntax that is of a specific language and of a specific grammar that must be decoded in the context of the surrounding tokens. You can't look at each byte or even each line in isolation and know exactly what to do next. The tokens in the language can't be taken in isolation like they can relative to the instructions of a VM.




     Another test of the difference between a VM and an interpreter is whether you think of it as being language independent. What we know as the Java VM is not really Java specific. You could make a compiler from other languages that result in byte codes that can be run on the JVM. On the other hand, I don't think we would really think of "compiling" some other language other than Python into Python for interpretation by the Python interpreter.

     The reason "virtual machine" is a more common term in Java and "interpreter" is a more common term in Python has a lot to do with the major difference between the two languages: static typing (Java) vs dynamic typing (Python). In this context, "type" refers to primitive data types -- types which suggest the in-memory storage size of the data. The Java virtual machine has it easy. It requires the programmer to specify the primitive data type of each variable. This provides sufficient information for Java bytecode not only to be interpreted and executed by the Java virtual machine, but even to be compiled into machine instructions. The Python virtual machine is more complex in the sense that it takes on the additional task of pausing before the execution of each operation to determine the primitive data types for each variable or data structure involved in the operation. Python frees the programmer from thinking in terms of primitive data types, and allows operations to be expressed at a higher level. The price of this freedom is performance. "Interpreter" is the preferred term for Python because it has to pause to inspect data types, and also because the comparatively concise syntax of dynamically-typed languages is a good fit for interactive interfaces. There's no technical barrier to building an interactive Java interface, but trying to write any statically-typed code interactively would be tedious, so it just isn't done that way.



     When you run myprog.py source file, the python interpreter first looks to see if any 'myprog.pyc' (which is the byte-code compiled version of 'myprog.py') exists, and if it is more recent than 'myprog.py'. If so, the interpreter runs it. If it does not exist, or 'myprog.py' is more recent than it (meaning you have changed the source file), the interpreter first compiles 'myprog.py' to 'myprog.pyc'. There is one exception to the above example. If you put '#! /usr/bin/env python' on the first line of 'myprog.py', make it executable , and then run 'myprog.py' by itself.

     Python is compiled but is not compiled to machine code ahead of time, it is only compiled to bytecode. These are instructions are similar to CPU instructions, but instead of being executed by the CPU, they are executed by software called a virtual machine. These are not same VM's that emulate entire operating systems, just a simplified CPU execution environment.