[Python-Dev] anonymous blocks

[Brian Sabbey]

Guido van Rossum wrote:
>> Why not have the block automatically be inserted into acquire's argument
>> list?  It would probably get annoying to have to define inner functions
>> like that every time one simply wants to use arguments.
>
> But the number of *uses* would be much larger than the number of
> "block decorators" you'd be coding. If you find yourself writing new
> block decorators all the time that's probably a sign you're too much
> in love with the feature. :-)

Ok, but in explanations of how to use such blocks, they appear about 
equally often.  They will therefore seem more difficult to use than they 
have to.

> I don't like implicit modifications of argument lists other than by
> method calls. It's okay for method calls because in the x.foo(a) <==>
> foo(x, a) equivalence, x is really close to the beginning of the
> argument list.

There is a rough equivalence:

@foo(x):
 	block

<==>

@foo(block, x)

Of course, the syntax does not allow such an equivalence, but conceptually 
it's there.

To improve the appearance of equivalence, the block could be made the last 
element in the argument list.

> And your proposal would preclude parameterless block decorators (or
> turn them into an ugly special case), which I think might be quite
> useful:
>
> @forever:
>    infinite loop body
>
> @ignore:
>    not executed at all
>
> @require:
>    assertions go here
>
> and so on.
>
> (In essence, we're inventing the opposite of "barewords" in Perl here, right?)

I don't understand this.  Why not:

@forever():
 	infinite loop body

etc.?  The same is done with methods: x.foo()  (or am I missing 
something?).  I actually prefer this because using '()' make it clear that 
you are making a call to 'forever'.  Importantly, 'forever' can throw 
exceptions at you.  Without the '()' one does not get this reminder.

I also believe it is more difficult to read without '()'.  The call to the 
function is implicit in the fact that it sits next to '@'.

But, again, if such argument list augmentation were done, something other 
than '@' would need to be used so as to not conflict with function 
decorator behavior.

-Brian