RE: [Python-Dev] Yet Another Decorator Syntax Suggestion (YADSS)
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@amor.org
On Mon, Mar 29, 2004 at 09:42:05AM -0800, Robert Brewer wrote:
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? ;)
Correct, it won't be any worse for classmethod and staticmethod decorators. grepping for decorators isn't currently a big deal, there aren't many to grep for. So as long as we're trying to put decorators where they will be noticed, we could umm, put decorators where they will be noticed. I was also taking shots at the 'def [classmethod] func(*args)' which makes parsing difficult by way of trying to make parsing intuitive. or something. -jackdied
participants (2)
-
Jack Diederich -
Robert Brewer