Steven D'Aprano <steve+comp.lang.pyt...@pearwood.info>:
> On Thu, 15 May 2014 17:12:57 +0300, Marko Rauhamaa wrote:
>> A definitive Python source file could be binary, XML, .py, .ast,
> Containing *what*? You can't just wave your hands and say "binary".
I sure can and am.
> Besides, where does the information inside the file come from?
The file would a canonical serialization of the AST. The information
would come from an editor (say, emacs) that displays the AST as
two-dimensional text according to your preferences.
Analogy: How do you edit a .png file? With an editor (say, gimp).
Programming languages could work the same way.
> Source code is, *by definition*, the definitive version.
The AST file would be the source code, only it wouldn't have line
numbers or columns. Maybe it could even leave out
capitalization/camel-casing so the editor can display the variable,
function and class names according to your preferences.
> The AST is not definitive. Human beings write *text*, which is what the
> source code is.
You are stuck to the status quo. I'm proposing the AST should be the
definitive source and the human beings would express AST through the
editor. Yes, it would probably be text, at least partly, but for example
the AST wouldn't specify the order of the function or class definitions.
> 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).
At least, we could stop debating silly surface presentation issues
(indentation, line width, spacing around operators...).
Well, actually, any .py file *does* specify a unique AST. Nothing would
prevent the text editor from presenting it according to your
preferences. They all do that to a degree anyway (colors, fonts), but
they could take even more liberties (which some IDE's do: hiding/showing
comments and function definitions).
There are tools that reindent and refactor code automatically. The text
editor could do that on the fly.