[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