Duncan Booth wrote: > 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.
No, I mean do other multi-line lambda design fix this problem somehow? It looks to me like the programmer's choice, quite simply. Both programs shown by [EMAIL PROTECTED] use lambda. The first one uses a decorator to actually define the wrapped function: @arg_range(5, 17) def f(arg): return arg*2 The arg_range function uses a nesting of two lambdas, yet the decorated function still has a name that nicely shows up in tracebacks. So in other words, lambdas and decorators play along nicely. f = arg_range(5, 17, lambda(arg)): return arg*2 Here, the programmer made a decision to define a global function using an assigment operator instead of def. The underlying function is the lambda itself. That is not a problem with the multi-line lambda. A lambda feature is not even required to do create a version of this problem: foo = arg_range(5, 17, bar) Now the function is called as foo(), but what the programmer sees in the traceback is "bar", which is potentially confusing. The traceback will show that bar() is being called from some given file and line number, but when that is inspected, there is no bar() there, only an expression which contains the function call foo() (and possibly other calls). I'm only interested in discussing the relative merits of my multi-line lambda proposal versus others. I'm not interested in debating people who think that other people who want multi-line lambdas should not have them. I also hope that everyone understands that lambdas, multi-line or not, are not the best tool for every situation for which they are a possible candidate. I agree with that, and am not interested in debating it either. It's off topic to the question of designing that labmda, except insofar as the design of the lambda influences whether or not lambda is a good choice in a situation. I.e. "lambda is a bad choice for this situation if it is designed like this, but not (or less so) if it is designed like this." > > 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. The problem there is that the programmer uses anonymous functions for class methods, rather than decorating named class methods. (Are anonymous class methods even possible? Lambdas can take an object as their first argument, but that's not the same thing.) > 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. "Pretty good guess" doesn't cut it. Fact is, that the identities of these functions are not unambiguously pinned down by their name alone; moreover, the line number and file information alone actually does precisely pinpoint the location of the exception. If only the names of functions appeared in the traceback, it would be less useful. If foo calls bar in three different places, you would not know which of those three places is responsible for the call of bar from foo. Moreover, in the bottom-most frame, you would not know which line in the function actually triggered the traceback. So I do not believe your claim that you rarely need to look at the line number information when comprehending tracebacks. -- http://mail.python.org/mailman/listinfo/python-list