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