Multi-line lambda proposal.

[Kaz Kylheku]

Duncan Booth wrote:
> One big problem with this is that with the decorator the function has a
> name but with a lambda you have anonymous functions so your tracebacks are
> really going to suck.

Is this an issue with this particular design that is addressed by other
designs?

Are the existing one-line lambdas free from this problem?

Is there really a problem? The Python tracebacks identify every frame
by file and line number, as well as name, if one is available.

Let me make the observation that  name of an inner function is, alone,
insufficient to identify that function in a debugging scenario. If you
have some inner function called I, defined within function F, you need
to know that it's the I inside F, and not some other I.

Look at what happens with:

>>> def err():
...   def inner():
...     return nonexistent
...   return inner
...
>>> err()
<function inner at 0x8177304>
>>> err()()
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "<stdin>", line 3, in inner
NameError: global name 'nonexistent' is not defined

In the traceback, the programmer is told that the error occured in a
function called inner. However, there could be many functions called
inner, including a global one. The programmer is not told that it's the
function inner which is defined inside the function err, which could be
done with some qualified name syntax like err.inner or whatever. So
this piece of information is about as useful as being told that it was
inside a lambda.

The real key which lets the programmer correlate the error back to the
source code is the file name and line number. When he locates that line
of code, then it's obvious---aha---it is in the middle of an inner
function called "inner", which also happens to be inside a global
function called "err".