[Python-Dev] anonymous blocks

[Paul Moore]

On 4/19/05, Brian Sabbey <sabbey at u.washington.edu> 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
> >
> > @EXPR:
> >    CODE
> >
> > 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.

Exactly.

Paul.