[Python-Dev] Yet Another Decorator Syntax Suggestion (YADSS)

[Robert Brewer]

Jack Diederich wrote:
> The more a proposal breaks grep, the less I like it.  Most decorator
> lists will be single decorators (if there is one at all).  
> Your suggestion
> (below) will always 'break' grep.  IDEs would alleviate the problem,
> but I've never used an IDE and I have no desire to start.
> 
> > 
> >     as:
> >         classmethod
> >     def func(arg):
> >         pass
> un-grepable! we'll never see the decorators.
> 
> def func(arg) [classmethod]: pass
> 
> grepable!
> 
> > This solution scales up reasonably to multiple decorators:
> >     as:
> >         runOnExit
> >         staticmethod
> >         syncronisedWith(attr='lock')
> >         attributedBy(
> >             author='MT',
> >             release='5.4'
> >         )
> >         returns(int)
> >         takes((int, int))
> >     def func(args):
> >         pass
> un-grepable!  regular funcs and decorated funcs grep the same.
> 
> def func(args) [runOnExit,
>                 ..
> grepable! the unterminated square brackets let us know we aren't
> seeing the full definition.
> 
> This is one of the reasons I dislike the decorator list between the
> 'def' and the function name.  I could grep for 'def.*?func(' but that
> is an annoyance from the command line, and a major pain in 
> most editors.
> 
> Even the current way is made grepable by popular convention,
> if the first argument is 'cls' instead of 'self' you expect it to be
> a classmethod.  If the first argument is neither 'cls' or 'self' it
> is a plain function or staticmethod (and you don't care which).
> Other decorators than these two are currently un-grepable.

Then Mike's proposal, to put decorators before the def, doesn't help or
hinder your current mechanism. You won't have to rewrite your greps at
all. Or are you proposing 'easier greps' as a high-priority requirement
for decorators? ;)


Robert Brewer
MIS
Amor Ministries
fumanchu at amor.org