[Python-ideas] Allow lambda decorators
carl at carlsensei.com
Mon Feb 9 05:08:25 CET 2009
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?
More information about the Python-ideas