[Compiler-sig] dipping my toe in...

[Jeremy Hylton]

>>>>> "SM" == Skip Montanaro <skip@pobox.com> writes:

  SM> Does the "?" imply the preceeding fields must be present if that
  SM> is?  For example, if we have an "inst", does that imply we also
  SM> have a "type" the same way optional args work in Python?

  Jeremy> It's not that powerful.  It just says that the type is
  Jeremy> optional.  So the Raise ctor above would actually accept a
  Jeremy> raise statement with only a traceback.

  SM> So the parser is the "guard at the gate" to prevent such stuff
  SM> from turning up in the AST?

Someone is responsible, but it's not clear who.  

In compile.c, there are a variety of tests that occur during code
generator, like illegal expressions as assignment targets.

In any particular implementation, the front end is going to produce
the AST.  It's got to guarantee that the AST is valid.

The ast module I'm working on will probably do those checks on the
completed AST before returning it.  But I haven't gotten that far
yet.  It might end up detecting the problem while creating the AST.
In fact, the expr_context patch I sent around earlier suggests that
the error would be determined sooner, because only valid expression
types have the expr_context slot.

  SM> I ask these because I'm still a little confused about what
  SM> exactly this stuff does.  Looking at test.py

  SM>     import ast print ast.transform("""global a, b, c a + b - c *
  SM>     3 """)

  SM> suggests that somehow it's parsing the Python code, but that's
  SM> not what's happening.

Actually, it is what's happening.  It compiles the source, then
converts it to an AST.

  SM> not what's happening.  Still, it's not clear why ast_transform
  SM> always returns None.

Only because there isn't anything else useful to return.  The AST is
not a PyObject *.  I thought about writing the pickling code and
returning a pickle, but that seemed like too much work.  Instead, I'm
just exercise the ast transformation code and then throwing away the
result.

(You may also have noticed that I never free any memory. :-)

  SM> Sorry for the frontal lobe density...

It's not your fault.  I'm not good at explaining what I'm currently
doing, and I haven't finished yet :-).

Jeremy