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
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4