> >> That's not the point, however. I'm trying to say that a processor >> cannot read a Python script, and since the Python interpreter as >> stored on disk is essentially an assembler file, > >It isn't; it's an executable.
I appreciated the intelligent response I received from you earlier, now we're splitting hairs. :-) Assembler, like any other higher level language is written as a source file and is compiled to a binary. An executable is one form of a binary, as is a dll. When you view the disassembly of a binary, there is a distinct difference between C, C++, Delphi, Visual Basic, DOS, or even between the different file types like PE, NE, MZ, etc. But they all decompile to assembler. While they are in the binary format, they are exactly that...binary. Who would want to interpret a long string of 1's and 0's. Binaries are not stored in hexadecimal on disk nor are they in hexadecimal in memory. But, all the 1's and 0's are in codes when they are instructions or ASCII strings. No other high level language has the one to one relationship that assembler has to machine code, the actual language of the computer. Dissassemblers can easily convert a binary to assembler due to the one to one relationship between them. That can't be said for any other higher level language. Converting back to C or Python would be a nightmare, although it's becoming a reality. Converting a compiled binary back to hexadecimal is basically a matter of converting the binary to hexadecimal, as in a hex editor. There are exceptions to that, of course, especially with compound assembler statements that use extensions to differentiate between registers. > >> any Python script must be sooner or later be converted to >> assembler form in order to be read by its own interpreter. > >This "assembler form" is commonly referred to as "Python byte code". > thanks for pointing that out. It lead me to this page: http://docs.python.org/lib/module-dis.html where it is explained that the opcodes are in Include/opcode.h. I'll take a look at that. The light goes on. From opcode.h: #define PRINT_NEWLINE_TO 74 All the ASCIi strings end with 0x74 in the disassembly. I have noted that Python uses a newline as a line feed/carriage return. Now I'm getting it. It could all be disassembled with a hex editor, but a disassembler is better for getting things in order. OK. So the pyc files use those defs...that's cool. -- http://mail.python.org/mailman/listinfo/python-list