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