> I see how it avoids needing to look at the parent node in general, but
> if we were compiling by recursively descending through the AST, then
> we would know whether Name's would be loads or stores by the time we
> got to them (we would already had to have visited an encompassing
> assignment or
> -It would be nice if decorators were passed a function's AST instead
> of a function object. As it is I have to use inspect.getsource to
> retrieve the source for the function in question, and then use
> ast.parse, which is a bit inefficient because the cpython parser has
> to already have done t
On Mon, Apr 6, 2009 at 1:33 AM, "Martin v. Löwis" wrote:
>> -If I have the source to a single function definition and I pass it to
>> ast.parse, I get back an ast.Module. Why not an ast.FunctionDef?
>
> Because it is easier for processing if you always get the same type of
> result. Typically, you
> -If I have the source to a single function definition and I pass it to
> ast.parse, I get back an ast.Module. Why not an ast.FunctionDef?
Because it is easier for processing if you always get the same type of
result. Typically, you don't know what's in the source code, so you
need to parse, then
Joseph Garvin writes:
> I decided to try using the ast module to see how difficult or not it
> was to use for metaprogramming.
Maybe you really want Lisp? ;-)
--
http://mail.python.org/mailman/listinfo/python-list
I decided to try using the ast module to see how difficult or not it
was to use for metaprogramming. So I tried writing a decorator that
would perform a simple transformation of a function's code. It was
certainly not as easy as I had guessed, but I did succeed so it's not
impossible. The issues I
