On 4/19/05, Brian Sabbey firstname.lastname@example.org wrote:
Guido van Rossum wrote:
@acquire(myLock): code code code
It would certainly solve the problem of which keyword to use! :-) And I think the syntax isn't even ambiguous -- the trailing colon distinguishes this from the function decorator syntax. I guess it would morph '@xxx' into "user-defined-keyword".
Hmm, this looks to me like a natural extension of decorators. Whether that is a good or a bad thing, I'm unable to decide :-)
[I can think of a number of uses for it, PEP 310-style with-blocks being one, but I can't decide if "lots of potential uses" is too close to "lots of potential for abuse" :-)]
How would acquire be defined? I guess it could be this, returning a function that takes a callable as an argument just like other decorators:
def acquire(aLock): def acquirer(block): aLock.acquire() try: block() finally: aLock.release() return acquirer
It really has to be this, IMO, otherwise the parallel with decorators becomes confusing, rather than helpful.
and the substitution of
would become something like
def __block(): CODE EXPR(__block)
The question of whether assignments within CODE are executed within a new namespace, as this implies, or in the surrounding namespace, remains open. I can see both as reasonable (new namespace = easier to describe/understand, more in line with decorators, probably far easier to implement; surrounding namespace = probably more useful/practical...)
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.
If this syntax is to be considered, in my view it *must* follow established decorator practice - and that includes the define-an-inner-function-and-return-it idiom.
Of course, augmenting the argument list in that way would be different than the behavior of decorators as they are now.