Re: Lambda binding solved by lateral thinking?

Guido.van.Rossum@cwi.nl
Tue, 01 Mar 1994 23:52:50 +0100

> Also: I think CSNS could be disastrous combined with Python's
> "create it if it ain't there" assignment and lack of declarations!

I guess this means death for CSNS in Python then. I tried pretending
that "global" wasn't needed for a long time but I was wrong. In
analogy, CSNS will require a corresponding extension to global, but I
don't think a reasonable syntax exists. (No need to propose
"func.attr" where "func" is an outer function, since "func" evaluates
to a function object and already has attributes...)

I still don't like the idea of making lambda "work right" (your words
not mine :) without also fixing local defs. The restriction of lambda
to a single expression will soon become a problem for fanatical
lambda-lovers, who will then complain that as soon as they need to
rewrite their lambda as a local 'def' the importation of variables
from the surrounding scope stops working. By requiring that lambda be
just syntactic sugar for a local def this complaint is avoided. So to
make lambda "work right" we need something that will also work for
local defs (QED).

How about the following piece of lateral thinking: add default
argument values, and evaluate the default values (once) in the
defining scope. This solves a totally unrelated problem (*args is
most often used to implement optional arguments) and can lead to
relatively clean code using "idiom" like the following:

def make_incrementor(incr):
return lambda x, incr=incr: return x + incr

or (without lambda):

def make_incrementor(incr):
def incrementor(x, incr=incr):
return x + incr
return incrementor

This should discourage abuse of nested scopes for structuring purposes
while satisfying the justifiable desire for importation of variables
from outer scopes into nested functions. (Note that no exportation is
supported!)

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