[Python-3000] parser/compiler interface [was Re: compiler module]

Georg Brandl g.brandl at gmx.net
Fri Jan 11 17:50:57 CET 2008

Martin v. Löwis schrieb:
>> * you can parse things with parser.suite(), but not create an AST from
>>    the parse result
>> * you can create an AST with an undocumented flag to compile(), but not
>>    compile the resulting AST
> The flag is documented, in the document referred to.
> There are good reasons for why things are that way. In proceeding, it
> is always important to remember these reasons.

I think I am aware of the reasons, and I'm not accusing anyone that
things went that way. It's just that a programmer would want a different
situation, especially with the compiler package gone.

>> * there are too many modules that have to do with parsing and compiling:
>>    token, symbol, parser, _ast, symtable
> I fail to see that as a problem. token and symbol are just collections
> of symbolic constants - what's wrong with that?

Nothing per se, but if we are grouping things for Py3k, this is a
strong candidate.

>> I'd suggest a single package to unify all this functionality and an API
>> that makes it easy to go from every compiling stage to the next, or to
>> the final code object.
> Unifying might be a good thing, but I don't see how it helps to solve
> the problems you report (except for the last one, perhaps - but then,
> you might end up with a single package with too many modules). To go
> from one step to the next, you first have to implement the code to make
> that possible.  Only then it becomes relevant whether that code all
> should live in a single package.

Of course, I intend to implement the missing pieces, as well as the


Thus spake the Lord: Thou shalt indent with four spaces. No more, no less.
Four shall be the number of spaces thou shalt indent, and the number of thy
indenting shall be four. Eight shalt thou not indent, nor either indent thou
two, excepting that thou then proceed to four. Tabs are right out.

More information about the Python-3000 mailing list