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