Re: Lambda binding solved?

Guido.van.Rossum@cwi.nl
Fri, 25 Feb 1994 15:01:12 +0100

I don't think Steven proposed this as a serious solution... But I
can't help pointing out some flaws.

Note that assigning anything except a dictionary object to the
func_globals attribute of a function will probably cause a core dump
if you call the function.

A safer approach would be to have a new built-in function bind() which
takes a function object and a dictionary as arguments and returns a
*new* function object which is the binding of the old function's code
object with the given dictionary. (This also keeps the idea of
functions as immutable objects, which I like.)

In private mail, Tim Peters proposed to extend lambda so that its
scope is merged with that of the surrounding function, arguing that
this is safe since a lambda can't modify its name space anyway.
However this would break the rule that a lambda expression is nothing
but syntactic sugar for a local function. I would rather (eventually)
go all the way and support general nested scopes -- as far as I can
remember the main reason not to support these was always mostly the
implementation effort, combined with a vague recollection that
unlimited nested scopes didn't work out that well in languages like
Algol-68.

Note that (unlike in the times when I originally opposed nested
scopes) references to globals can still be implemented efficiently
since the "compiler" already collects a list of locals per function.
A problem might be how to extende the "global" statement to allow
assignments to variables at an intermediate scope.

Personally, I'd hate to see a Python programming style develop where
people code their entire program as a set of nested functions, a la
Pascal -- I'd much rather encourage people to use a more
object-oriented style instead based upon multiple modules instead.

--Guido van Rossum, CWI, Amsterdam <Guido.van.Rossum@cwi.nl>
URL: <http://www.cwi.nl/cwi/people/Guido.van.Rossum.html>

PS It don't think the argument exists that will convince *me* that
Python needs explicit open/close brackets, even optional ones. So
you're all wasting your breath on that one :-)