[Python-ideas] Allow lambda decorators

[Carl Johnson]

On 2009/02/08, at 5:29 pm, Guido van Rossum wrote:

> I'm sorry, but you are using two nested lambdas plus a list
> comprehension, and three nested functions here, plus one more list
> comprehension for showing the result. My brain hurts trying to
> understand all this. I don't think this bodes well as a use case for a
> proposed feature.
>
> I'm not trying to be sarcastic here -- I really think this code is too
> hard to follow for a motivating example.

I will admit that this is getting a bit too functional-language-like  
for its own good, but (ignoring my proposed solution for a while) at  
least in the case of the nested scope problem, what other choices is  
there but to nest functions in order to keep the variable from  
varying? I myself was bitten by the variable thing when I wanted to  
write a simple for-loop to add methods to a class, but because of the  
scoping issue, it ended up that all of the methods were equivalent to  
the last in the list. At present, there's no way around this but to  
write a slightly confusing series of nested functions.

So, that's my case for an each_in function. Going back to the @lambda  
thing, in general, people are eventually going to run into different  
situations where they have to write their own decorators. We already  
have a lot of different situations taken care of for us by the  
functools and itertools, but I don't think the library will ever be  
able to do everything for everyone. I think that the concept of  
writing decorators (as opposed to using them) is definitely confusing  
at first, since you're nesting one thing inside of another and then  
flipping it all around, and it doesn't entirely make sense, but the  
Python community seems to have adapted to it. For that matter, if I  
think too much about what happens in a series of nested generators, I  
can confuse myself, but each individual generator makes sense as a  
kind of "pipe" through which data is flowing and being transformed.  
Similarly, metaclasses are hard to understand but make things easy to  
use. So, I guess the key is to keep the parts easy to understand even  
if how the parts work together is a bit circuitous. Maybe @lambda  
isn't accomplishing that, but I'm not sure how much easier to  
understand equivalent solutions would be that is written without it.  
Easy things easy, hard things possible?

-- Carl