[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