[Python-ideas] exec_closure (was Re: Assignment decorators)

[Eric Snow]

During sprints I spent some time getting cozy with the python internals and
the result is an exec_closure function I've put in an extension module.
 Essentially, it exposes the PyEval_EvalCodeEx function, so you can do execs
with closures and arbitrary code objects, like Nick suggested.  He more or
less mentored me through this, my first foray into the Underlying C code, so
thanks Nick!  In the next week I intend on cleaning it up, putting it on
PyPI, and writing a bit about it.  One example I hope to make is how to
simulate a def-from using a decorator.  My hope is to add new, meaningful
capability to python, so we'll see how it goes.

-eric

On Thu, Mar 10, 2011 at 7:31 PM, Nick Coghlan <ncoghlan at gmail.com> wrote:

> On Thu, Mar 10, 2011 at 2:02 PM, Guido van Rossum <guido at python.org>
> wrote:
> > On Thu, Mar 10, 2011 at 11:41 AM, Paul Moore <p.f.moore at gmail.com>
> wrote:
> >> On 10 March 2011 12:49, Nick Coghlan <ncoghlan at gmail.com> wrote:
> >>> I actually agree it is a major weakness of the syntax. You can play
> >>> games with "from" to rearrange the line. For example:
> >>>
> >>> def name from builder(param_spec):
> >>>  code_block
> >>>
> >>> as sugar for:
> >>>
> >>> name = builder("name", param_spec_obj, code_obj)
> >>
> >> Yes, I like that better...
> >
> > I'd like it better if it came with a default builder implementation
> > that would create regular functions, so that
> >
> > def name(<params>):
> >  <block>
> >
> > was equivalent to
> >
> > def name from <defaultbuilder>(<params>):
> >  <block>
>
> Yeah, I was thinking that having builde equivalents for functions and
> generators would be an interesting way to go. Builder objects may need
> to be passed some extra parameters to make that feasible, though
> (specifically, a reference to globals(), as well as the closure
> fulfilment details).
>
> One interesting side effect of that is the ability to have a
> never-yields generator without having to insert a dummy never-executed
> yield statement anywhere.
>
> > But I don't see a reasonable way to do that.
> >
> > Also I think it's confusing to have both
> >
> > @some_magic
> > def name(<params>): ...
> >
> > and
> >
> > def name from some_magic(<params): ...
> >
> > with different semantics.
>
> Don't forget:
>
> @more_magic
> def name from some_magic(params):
>     code
>
> I'm *far* from convinced this is a good idea, but it at least meets
> the holder of making something new possible.
>
> If exec() was enhanced to allow correct execution of closures and code
> blocks expecting arguments, you could experiment with this using a
> decorator and extracting the various pieces from a function object
> after it had already been created.
>
> Cheers,
> Nick.
>
> --
> Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia
> _______________________________________________
> Python-ideas mailing list
> Python-ideas at python.org
> http://mail.python.org/mailman/listinfo/python-ideas
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20110317/97c526f5/attachment.html>