Multi-line lambda proposal.
duncan.booth at invalid.invalid
Thu May 11 19:20:38 CEST 2006
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.
More information about the Python-list