[Python-Dev] Re: "groupby" iterator

[Michael Hudson]

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.

Yes.  I think I used .c() for that.  IIRC correctly, I also
complicated things to the extent that there was a special object, say
N, and you could write

>>> map(X.split(N), ['a a', 'b b\nb'], [None, '\n'])
[['a', 'a'], ['b b', 'b']]

This might be going a bit far...

> It could probably be made quite fast with a C implementation.

Would be tedious to write though :-)

> 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.

I am not a fan of the idea of compiling certain kinds of lambdas
differently.

Cheers,
mwh

-- 
  While preceding your entrance with a grenade is a good tactic in
  Quake, it can lead to problems if attempted at work.    -- C Hacking
               -- http://home.xnet.com/~raven/Sysadmin/ASR.Quotes.html