On Thu, 15 May 2014 17:12:57 +0300, Marko Rauhamaa wrote:

> A definitive Python source file could be binary, XML, .py, .ast,
> whatever, 

Containing *what*? You can't just wave your hands and say "binary". What 
sort of binary file? Perhaps a JPEG file, where red triangles of 
different sizes represent keywords. Variable names can be encoded using a 
pattern of purple dots. Expressions and blocks of code can be formed by 
joining components with lines. Operators by squares of different colours 
(green means +, blue means -, etc.).

No? Then what?

Besides, where does the information inside the file come from? You surely 
don't expect people to write the binary data/AST/whatever directly. How 
can the zip file be "definitive" when it is derived from something more 

Source code is, *by definition*, the definitive version. (It's the 
SOURCE, see?) Zipping the source code just means that the *source* inside 
the zip file is the definitive version, not the compressed binary data.

The AST is not definitive. Human beings write *text*, which is what the 
source code is. It may be text with an especially restrictive grammar, 
but it's still text. Everything else -- the parse tree, the abstract 
syntax tree, the byte code, the machine code, the compressed text, 
encrypted text, the pixel rendering of the text, ... are derived from the 
code as written by human beings.

Code is written primarily for human beings. Many programmers, and many 
language designers, don't realise this, which is why so many programs are 
write-only code. Presentation *is important*, and cannot always be 
separated from semantics without hurting the primary audience, the human 
reader. This is what code obfuscators do, deliberately: mangle the 
presentation while keeping the semantics the same. You're inadvertently 
proposing the same thing (albeit to a lesser degree).

Steven D'Aprano

Reply via email to