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