[Python-Dev] code blocks using 'for' loops and generators
Brian Sabbey
sabbey at u.washington.edu
Tue Mar 15 02:07:05 CET 2005
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.
> 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 for something that would be rarely used, I do
not think 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.
-Brian
More information about the Python-Dev
mailing list