Sorry to have confused yall. What I meant was that you can do something like this, where the fucntion isn't called until it is bount to () with the right params<br><br>>>> def a():<br>...     print "inside a"<br>
... <br>>>> def b():<br>...     print "inside b"<br>... <br>>>> def c(a,b):<br>...     a()<br>...     b()<br>... <br>>>> d={c:(a,b)}<br>>>> d[c][0]()<br>inside a<br>>>> d[c][1]()<br>
inside b<br>>>> d[c(d[c][0],d[c][1])]<br>inside a<br>inside b<br>Traceback (most recent call last):<br>  File "<stdin>", line 1, in <module><br>KeyError: None<br><br>where function a and b are bound in function c<br>
<br clear="all">-Alex Goretoy<br><a href="http://www.goretoy.com">http://www.goretoy.com</a><br><br>Samuel Beckett  - "Birth was the death of him."
<br><br><div class="gmail_quote">On Sun, Mar 22, 2009 at 2:42 PM, R. David Murray <span dir="ltr"><<a href="mailto:rdmurray@bitdance.com">rdmurray@bitdance.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="im">"Gabriel Genellina" <<a href="mailto:gagsl-py2@yahoo.com.ar">gagsl-py2@yahoo.com.ar</a>> wrote:<br>
> En Fri, 20 Mar 2009 23:16:00 -0300, alex goretoy<br>
> <<a href="mailto:aleksandr.goretoy@gmail.com">aleksandr.goretoy@gmail.com</a>> escribió:<br>
><br>
> > i looks at lambdas as unbound functions(or super function), in the case<br>
> > above we create the functions in a list places it in memory unboud, once<br>
> > binding a call to the memory address space it returns the value<br>
> ><br>
> > it is basically same as doing this:<br>
> > def f():<br>
> >     print "f"<br>
> ><br>
> > a=f #unbound function, same as rename function<br>
> > a() #bind call to address space<br>
><br>
> Mmm, I don't quite understand what you said. lambda creates functions that<br>
> aren't different than functions created by def: apart from the name,<br>
> they're really the same thing.<br>
<br>
</div>Oh, good, I'm not the only one for whom the above didn't make sense :)<br>
I feel a little less dense now.<br>
<div class="im"><br>
> And if you imply that *where* you call a function does matter, it does<br>
> not. A function carries its own local namespace, its own closure, and its<br>
> global namespace. At call time, no additional "binding" is done (except<br>
> parameters -> arguments).<br>
><br>
> (and the address space is always the one of the running process)<br>
<br>
</div>I poked around in the API docs and experimented with func_closure and<br>
related attributes, and after bending my brain for a while I think I<br>
understand this.  The actual implementation of the closure is a single<br>
list of 'cell' objects which represent namespace slots in the nested<br>
scopes in which the closed-over function is defined.<br>
<br>
But the fact that it is a single list is an implementation detail, and<br>
the implementation is in fact carefully designed so that conceptually<br>
we can think of the closure as giving the function access to those<br>
nested-scope namespaces in almost(*) the same sense that it has a<br>
reference to the global and local namespaces.  That is, if what a name<br>
in _any_ of those namespaces points to is changed, then the closed-over<br>
function sees those changes.<br>
<br>
In this way, we understand the original example:  when defining a<br>
lambda having a 'free variable' (that is, one not defined in either the<br>
local or global scope) that was a name in the surrounding function's<br>
local namespace, the lambda is going to see any changes made by the<br>
surrounding function with regards to what that name points to.  Thus,<br>
the final value that the lambda uses is whatever the final value of the<br>
for loop variable was when the surrounding function finished executing.<br>
<br>
However, I think that a Python closure is not quite the same thing as a<br>
'computer science' closure, for the same reason that people coming from a<br>
language with variables-and-values as opposed to namespaces get confused<br>
when dealing with Python function call semantics.  Consider:<br>
<br>
    <a href="http://en.wikipedia.org/wiki/Closure_%28computer_science%29" target="_blank">http://en.wikipedia.org/wiki/Closure_(computer_science)</a><br>
<br>
That says that a closure can be used to provide a function with a private<br>
set of variables that persist from one invocation to the next, so that<br>
a value established in one call can be accessed in the next.  The last<br>
part of that sentence is not true in Python, since any assignment inside<br>
a function affects only the local (per-invocation) namespace or (given<br>
a global statement) the global namespace.  A function cannot change the<br>
thing pointed to by a name in the closure.  Only the outer function,<br>
for whom that name is in its local namespace, can do that.<br>
<br>
(*) That last sentence in the previous paragraph is why I said '_almost_<br>
the same sense' earlier: a function can modify what names point to in<br>
its local and global namespaces, but cannot modify what names point to<br>
in the closure namespace.<br>
<br>
Of course, we can produce the same _effect_ as a computer science closure<br>
in Python by using mutable objects...which is exactly parallel to the<br>
difference between passing mutable or immutable objects in a function<br>
call.<br>
<div class="im"><br>
--<br>
R. David Murray           <a href="http://www.bitdance.com" target="_blank">http://www.bitdance.com</a><br>
<br>
--<br>
</div><div><div></div><div class="h5"><a href="http://mail.python.org/mailman/listinfo/python-list" target="_blank">http://mail.python.org/mailman/listinfo/python-list</a><br>
</div></div></blockquote></div><br>