[Python-Dev] code blocks using 'for' loops and generators

[Samuele Pedroni]

Brian Sabbey wrote:
> 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.