<div dir="ltr">On Mon, Oct 13, 2008 at 2:05 PM, Arnaud Delobelle <span dir="ltr"><<a href="mailto:arnodel@googlemail.com">arnodel@googlemail.com</a>></span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div><div></div><div class="Wj3C7c"><br>
On 13 Oct 2008, at 15:22, George Sakkis wrote:<br>
<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
On Mon, Oct 13, 2008 at 8:09 AM, Arnaud Delobelle <<a href="mailto:arnodel@googlemail.com" target="_blank">arnodel@googlemail.com</a>> wrote:<br>
<br>
> Since this idea didn't get much steam, a more modest proposal would be to<br>
> relax the restriction on cells: allow the creation of new cells and the<br>
> rebinding of func_closure in pure Python. Then one could explicitly create a<br>
> new scope without any other change in the language through a 'localize'<br>
> decorator that would create a new cell for every free variable (i.e. global<br>
> or value from an enclosing scope) of the function:<br>
><br>
> lst = []<br>
> for i in range(10):<br>
> @localize<br>
> def f(): print i<br>
> lst.append(f)<br>
> lst.append(localize(lambda: i**2))<br>
><br>
> I'd love to be proven wrong but I don't think localize() can be implemented<br>
> in current Python.<br>
<br>
I think you probably can in CPython, but that would involve bytecode<br>
introspection and using ctypes.pythonapi.PyCell_New, and it would be<br>
terribly inefficient. I wrote a similar decorator that takes a<br>
function and bind some of its variables to some values. e.g<br>
<br>
@bind(x=40, y=2)<br>
def foo(): return x+y<br>
<br>
>>> foo()<br>
42<br>
<br>
It's useless of course.<br>
<br>
Can you expand a bit on that ? Why would it be terribly inefficient and why is it useless ?<br>
</blockquote>
<br></div></div>
When I was saying it was useless, I was talking about my bind decorator of course!<br>
<br>
It's useless because the above can be written<br>
<br>
def foo(x=40, y=2): return x+y</blockquote><div><br>But the whole point of this thread is that this is an abuse of default arguments since it changes f's signature; f(5,6), f(1), f(y=10) should all raise TypeError.<br>
<br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
It's inefficient because it works by deconstructing and reconstructing the function bytecode.</blockquote><div><br>But this happens only once at decoration time, not every time f is called, right ?<br><br>George<br><br>
</div></div></div>