[Python-Dev] Re: "groupby" iterator
Thomas Heller
theller at python.net
Tue Dec 2 15:56:41 EST 2003
Guido van Rossum <guido at python.org> writes:
>> > It would let you do things like
>> >
>> >>>> map(X + 1, range(2))
>>
>> Something like this?
>>
>> class Adder:
>> def __init__(self, number):
>> self._number = number
>> def __call__(self, arg):
>> return arg + self._number
>>
>> class X:
>> def __add__(self, number):
>> return Adder(number)
>>
>> X = X()
>>
>> print map(X + 1, range(2))
>
> Ah, of course. Nice. This can be extended to __getattr__ and
> __getitem__; unfortunately __call__ would be ambiguous. It could
> probably be made quite fast with a C implementation.
>
> Now the question remains, would it be better to hide this and simply
> use it under the hood as an alternative way of generating code for
> lambda, or should it be some sort of standard library module, to be
> invoked explicitly? In favor of the latter pleads that this would
> solve the semantic differences with lambda when free variables are
> involved: obviously X+q would evaluate q only once, while
> (lamda X: X+q) evaluates q on each invocation. Remember that for
> generator expressions we've made the decision that
> (X+q for X in seq)
> should evaluate q only once.
The latter has another advantage (or is this a disadvantage of the
former?): You can invoke
lambda x: x.something
with a keyword arg, which would not be possible with a C implemented
function, I assume. lambda expressions are often used to implement gui
callbacks, and they are sometimes invoked this way.
So the former would introduce incompatibilities.
Thomas
More information about the Python-Dev
mailing list