[Python-ideas] def-from

Tue Mar 29 19:40:41 CEST 2011

On Tue, Mar 29, 2011 at 10:26 AM, Eric Snow <ericsnowcurrently at gmail.com> wrote:
> 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.

I'm glad you went down this particular rabbit hole in so much detail.
You have proved beyond a doubt that the idea is not compatible with
how Python currently compiles code, since it would mean that you
couldn't save the generated bytecode to a .pyc file just by parsing
and compiling the source code -- either you'd have to have the runtime
environment available to generate the bytecode, or you'd have to put
off generating the bytecode until much later.

(I knew this all along, but had a hard time explaining it to the
proponents of things like this, or the "make" statement, etc. -- many
people have quite a misguided idea about how dynamic Python really is,
and this doesn't stop them from proposing changes that only make sense
in the alternate reality they believe they live in.)

> 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.

Yeah, this is a nice reduction to the absurd of the original idea; the
contradiction you've arrived at proves that the original idea cannot
work.

> 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?

To me, the idea has always been dead. I'm glad you've provided the
supporting documentation of its demise.

-- 
--Guido van Rossum (python.org/~guido)