On 4/19/05, Brian Sabbey <[EMAIL PROTECTED]> 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. _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
