[Python-Dev] anonymous blocks

[Brian Sabbey]

Guido van Rossum wrote:
>> See the thread "pre-PEP: Suite-Based Keywords" (shamless plug)
>> (an earlier, similar proposal is here:
>> http://groups.google.co.uk/groups?selm=mailman.403.1105274631.22381.python-list
>> %40python.org ).
>>
>> In short, if doFoo is defined like:
>>
>> def doFoo(func1, func2):
>>         pass
>>
>> You would be able to call it like:
>>
>> doFoo(**):
>>         def func1(a, b):
>>                 return a + b
>>         def func2(c, d):
>>                 return c + d
>>
>> That is, a suite can be used to define keyword arguments.
>
> I'm still not sure how this is particularly solving a pressing problem
> that isn't solved by putting the function definitions in front of the
> call. I saw the first version of the proto-PEP and didn't think that
> the motivating example (keeping the getx/setx methods passed to a
> property definition out of the class namespace) was all that valuable.

OK.  I think most people (myself included) who would prefer to define 
properties (and event handlers, etc.) in this way are motivated by the 
perception that the current method is just ugly.  I don't know that it 
solves any pressing problems.

> Two more issues:
>
> (1) It seems that *every* name introduced in the block automatically
> becomes a keyword argument. This looks like a problem, since you could
> easily need temporary variables there. (I don't see that a problem
> with class bodies because the typical use there is only method and
> property definitions and the occasional instance variable default.)

Combining the suite-based keywords proposal with the earlier, 'where' 
proposal (linked in my above post), you would be able to name variables 
individually in the case that temporary variables are needed:

f(x=x):
 	x = [i**2 for i in [1,2,3]]

> (2) This seems to be attaching a block to a specific function call but
> there are more general cases: e.g. you might want to assign the return
> value of doFoo() to a variable, or you might want to pass it as an
> argument to another call.

The 'where' proposal also doesn't have this problem.  Any expression is 
allowed.

> *If* we're going to create syntax for anonymous blocks, I think the
> primary use case ought to be cleanup operations to replace try/finally
> blocks for locking and similar things. I'd love to have syntactical
> support so I can write
>
> blahblah(myLock):
>    code
>    code
>    code
>
> instead of
>
> myLock.acquire()
> try:
>    code
>    code
>    code
> finally:
>    myLock.release()

Well, that was my other proposal, "pre-PEP: Simple Thunks" (there is also 
an implementation).  It didn't seem to go over all that well.  I am going 
to try to rewrite it and give more motivation and explanation (and maybe 
use 'with' and 'from' instead of 'do' and 'in' as keywords).

-Brian