Samuele Pedroni wrote:
OTOH a suite-based syntax for thunks can likely not work as a substitute of lambda for cases like:
f(lambda: ..., ...)
where the function is the first argument, and then there are further arguments.
I do not see why you say suite-based thunks cannot be used in the case in which the function takes more than one argument. Using the syntax I described earlier, they work in just that way:
def pickled_file(thunk, name): ... new_data = thunk(pickle.load(f)) ...
with greetings from pickled_file('greetings.pickle'): ... value greetings
One can make an analogy with "self". Both the thunk and self can be passed automatically as the first argument, and further arguments can follow. In this way, functions that already take a thunk as a first argument (such as sort) can be re-used without modification.
Of course now one has a problem with things that take functions as last arguments, wich if I rembember correctly is the natural position in Ruby. Unless the syntax involve placeholders (likely icky) one is going to have this kind of limitations. My point is that a suite-based syntax can only be a half substitute for lambda and anyway requiring a suite seems overkill and unnatural for the just 1 expression case, for example predicates. IOW a suite-based syntax is not a lambda killer in itself, I would not try to stress that point.
Apart this one very hard problem, it would be nice to be able to define
and pass more thunks simultaneously. In particular a more concise syntax for
def setx(self, v): self._x = v def getx(self): return self._x x = property(getx,setx)
was considered in the past discussions about the topic a worthy goal.
Here I can make another analogy with self. Just as python does not give syntactic support for multiple dispatch because (I assume) it would require major syntax changes
multiple dispatch has nothing to do with syntax, in fact usual call syntax is sufficient, and people do use multiple dispatch sometimes, and decorators now can be even used to sugar up the definition side of it.
for something that would be rarely used, I do not think
well that's up to discussion to discover
it is worth it to give syntactic support for multiple
thunks. If only a fraction "epsilon" of functions take a single thunk, then I would guess that "epsilon**2" take two thunks, and it is not worth creating syntax for such a small number of cases, especially if that syntax compromises what would otherwise be a much cleaner syntax for the single thunk case.
well, but this is stated without even trying to come up with a syntax for that case. Notice that the first time around Guido himself would have preferred if achievable a multithunk syntax, he obviously can have changed his mind. But, yes, syntax vs expressivity is the key issue here. _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
