[Python-Dev] Re: "groupby" iterator
Guido van Rossum
guido at python.org
Tue Dec 2 14:18:56 EST 2003
> > I agree with Thomas - rather than adding yet more specialised
> > functions, it would seem more sensible to optimize lambda - probably
> > via special cases like this.
>
> One question that remains is: do a handful of these specialized
> functions make it possible to replace the remaining uses lambda
> completely?
>
> Looking at parts of my codebase nearly all uses of lambda are
> 'lambda self: self.someattr'.
Aha. Very interesting ideas both!
In the past, we had a similar issue with exec/eval. We looked at the
most frequent uses of these, and found that getting an attribute with
a computed name was the most common, so we added getattr (and setattr
and delattr). Importing a module with a computed name was also quite
common, and now we have __import__. So now exec/eval are typically
only used when we *really* want to run code provided by an end user.
(Exception: I often use eval() to parse literals when I know it is a
literal but it can have several types, e.g. string, int, float. Maybe
there's a restricted form of eval that could be used for this too?)
So again, here we have a mechanism that's rather generic (lambda)
which is frequently used in a few stylized patterns (to extract an
attribute or field). So Raymond's new functions attrgetter and
itemgetter (whose names I cannot seem to remember :-) take care of
these.
But, at least for attrgetter, I am slightly unhappy with the outcome,
because the attribute name is now expressed as a string literal rather
than using attribute notation. This makes it harder to write
automated tools that check or optimize code. (For itemgetter it
doesn't really matter, since the index is a literal either way.)
So, while I'm not particularly keen on lambda, I'm not that keen on
attrgetter either. But what could be better? All I can think of are
slightly shorter but even more crippled forms of lambda; for example,
we could invent a new keyword XXX so that the expression (XXX.foo) is
equivalent to (lambda self: self.foo). This isn't very attractive.
Maybe the idea of recognizing some special forms of lambda and
implementing them more efficiently indeed makes more sense!
Hm, I see no end to this rambling, but I've got to go, so I'll just
stop now...
--Guido van Rossum (home page: http://www.python.org/~guido/)
More information about the Python-Dev
mailing list