Creating functions programmatically

[Martin v. Löwis]

> Next step is to programmatically create functions objects from token
> sequences representing argument lists and function bodies.  This
> shouldn't be so hard, if nothing else I can invent a unique name,
> create a full textual function definition and 'exec' it in an
> appropriate dict.

That is a reasonable strategy.

> But perhaps someone can point me to a better way?  I am slightly
> overwhelmed by the many options python has to offer for dealing with
> python code (compiler, compiler.{pycodegen,symbols,syntax,..}, new,
> ast, code, py_compile, compile, exec, eval, ...).

I recommend to ignore most of these. Each of them was created to scratch
someone's itch, and then turned out not to be applicable for a more
general, or slightly different use case.

> The 'compile' builtin in combination with new.function looked
> promising at first, but I can't see how to make that work for
> functions that take arguments and return values.

Yes, if you want to compile a function, you really need the function
header, or else the compiler can't tell what the local variables are.

> One thing that I don't see how to achieve with exec is control over
> location in diagnostic messages.  Regular Python diagnostics are fine,
> but file and line should not point to the exec statement in the .py
> file, but to the appropriate place in the file I'm parsing.  I could
> use something akin to C's #line here, is there any Python equivalent?

Unfortunately, no. *That* is something that the compiler package should
help to implement: the compiler package is supposed to mimic the builtin
compile function 1:1, but it is pure Python. and provides various hooks
(usually by allowing you to inherit from some class).

> or-have-I-really-found-something-that-C-can-do-but-Python-can't?-ly

can't-possibly-do certainly not, but C has this out of the box; Python
doesn't.

Regards,
Martin