> > 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. --Guido van Rossum (home page: http://www.python.org/~guido/)
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