compiling to python byte codes

["Martin v. Löwis"]

Maurice LING wrote:
> Can I feed a python source file into compile(), line by line, and expect 
> it to generate a working .pyc file? 

compile() requires the complete source code. However, it might be that
the complete source code is just a single statement, or a single
function exectuting a single statement.

Did you read the documentation of compile()? It would have told you that
compile() does not generate .pyc files at all. Instead, it generates
code objects, and you use the marshal module to save them into .pyc
files.

> I suppose my intended use is to be 
> able to handle python codes written at run time, to execute python codes 
> line by line, in a python program. 

Single-step execution is an issue entire independent of generating
Python bytecode, or source code. Regardless of how you have generated
the Python bytecode (directly, or through source code), Python supports
single-stepping of byte code (on a line-per-line-of-source-code basis).

However, when you generate Python code (source or byte), and you know
you are going to need single-stepping, you should put single-stepping
*into the generated code*. I.e. if your input language reads

   action 1
   action 2
   action 3

you generate

def program():
   starting()
   do_action_1()
   step_done()
   do_action_2()
   step_done()
   do_action_3()
   step_done()

Then, a proper implementation of step_done() will allow for user
interaction, giving you single-step capabilities.

> I was thinking that it may be simpler to say, write a PHP-to-Python 
> compiler which compiles PHP into an intermediate form, which is then 
> converted into python bytecodes, rather than trying to automate source 
> code conversion from PHP to Python. Well, PHP is just an off-hand 
> example, it may be COBOL or Pascal. Any ideas?

No. Generating source code is *always* simpler. There are three reasons
why one would not generate source code even though it is simpler:
- you don't have a compiler for the source code available on the target
   system. This is the compile-to-JVM example.
- the compiler for the source language is gives inefficient byte code,
   and you can do better. Although it is theoretically possible, it is
   unlikely to happen in practice (not because the compiler is already
   optimal, but because it is very difficult to do better - if it wasn't,
   the authors of the compiler would have improved it already)
- certain VM opcodes are not available through source code. This sounds
   theoretical, too - why would the VM include opcodes that will never
   occur in practice? The real-world example is .NET, though, which
   supports many languages, and thus supports constructs not available
   in, say, C# (like global fields). This is not the case for Python,
   though: Python uses virtually all of its opcodes.

Regards,
Martin