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". -- http://mail.python.org/mailman/listinfo/python-list