Mailman 3 def-from - Python-ideas

29 Mar 2011

      During the discussion about assignment decorators Nick brought up the idea
of adding a def-from syntax:

def <NAME> from <BUILDER>(<ARGS>):
    ...

which would effectively call

<BUILDER>(<NAME>, <ARGS>, <BODY>)

This is much like how meta-classes work, though this would be with functions
(sort of meta-functions).  Ultimately, they would amount to the same thing.
 The current "def" statement would just have an implicit builder.

During the sprints I explored the idea of this with Nick by making a
"build_from" decorator, and an exec_closure builtin to provide the full
capability needed to emulate the def-from syntax with a code object.  It
turned out the exec_closure didn't buy much.  However, one thing that became
apparent in discussing this with Nick is that just passing the code object
of the decorated function (or of the def body) as <BODY> doesn't buy much.
 To really get much bang out of this you would need to pass the AST of the
body.  With the AST you could manipulate it as needed before compiling.
 (Nick's idea)  Suddenly class definitions are just a special case of
def-from.

If you really wanted to get crazy you could pass the raw string as <BODY>
(can't blame this one on Nick).  With the raw string you could put just
about anything in there, like a DSL or another programming language.  Then
parse it however you like, and use that result to compile something else or
build some data set or call some external library or whatever you care to do
with raw data.  It would not be restricted to parsable Python  In the normal
"def" context Python is hardwired to turn it into a function code object,
and the implicit builder to generate the function object thereon.

I am reticent to suggest adding undue complexity to the languge or adversely
affect readability (potentially) if it doesn't offer plenty of increased
expressive power.  So, crazy raw string thing aside, how about the def-from
syntax, particularly with the AST passed?  Nick already indicated to me that
we probably should get comfy with metaclass __prepare__ before we get any
more metaprogramming, and he's probably right.  I was thinking about
implementing def-from as an exercise in syntax hacking, regardless.  Any
thoughts?  Are there better syntax hacking exercises (like Raymond's "def
x.y(..." or "x.y = ..." or "x.(name)"?  Could def-from have a place in the
future?

-eric

def-from

Eric Snow

Eric Snow

Guido van Rossum

Eric Snow

Eric Snow

Guido van Rossum

MRAB

Eric Snow

tags

participants (3)