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

Robert Brewer fumanchu at amor.org
Mon Mar 29 12:42:05 EST 2004

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

More information about the Python-Dev mailing list