Multi-line lambda proposal.

[Duncan Booth]

Kaz Kylheku wrote:

> 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?

Yes. Decorators don't interfere with the name of the underlying function 
displayed in tracebacks.

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

No, but since a single line lambda does virtually nothing it isn't as 
serious. Decorators are useful enough that in some situation you might 
decorate every method in a class (e.g. for a web application you might 
apply security settings with decorators). In that situation you have just 
messed up every stack frame in every traceback.
> 
> Is there really a problem? The Python tracebacks identify every frame
> by file and line number, as well as name, if one is available.

Great, and I suppose that if they printed out the line numbers in binary 
that wouldn't make it harder to understand the traceback either. I end up 
reading tracebacks quite a lot, and it is the sequence of the function 
names which matter first, I don't usually need to go and look at the file 
and code lines.

> 
> 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.
> 
If the stack frame shows I called from F then it is usually a pretty good 
guess that it means the I inside F. Besides, I don't usually name all my 
inner functions I; I find that giving them meaningful names tends to help.