tweaking @decorator syntax

John Marshall John.Marshall at ec.gc.ca
Thu Aug 5 16:17:25 CEST 2004


On Thu, 2004-08-05 at 08:41, Sandy Norton wrote:
> On 4 Aug 2004, Christopher T King wrote:
>     
> > Of course, I prefer the nested block idea better (either with a new
> > keyword or new syntax), but I don't see those (especially the syntax one) 
> > flying anytime soon.
> 
> I know further discussion of this topic is feeling futile, but one can only hope.
> 
> > Unless someone can come up with an idea everyone can agree on Real Soon 
> > Now, I think the whole idea should be dropped and wait until 3.0.  We'll 
> > have plenty of time to argue about it then.
> 
> Agreed.
> 
> > Sorry about the long rant, but it felt good to get that all off my chest.
> 
> Please, we need more rants like yours. Now if they could somehow 
> collectively become a 'public outcry' (-;
> 
> I realize my hasty initial post didn't actually show the present 2.4 form, 
> so I've included it and added your variations for the sake of comparison:
> 

With the current choice and the list of alternatives you gave,
two things struck me about the location of the decorators
in the current choice:
    1) They seem to be in the wrong place with respect to
       what they are affecting.
    2) Can decorators easily be extended to apply to class
       and module?

Whether or not the @ or some other operator/keyword/etc. is
used, what is more easily understandable/readable?
-----
class Klass:
    def __init__(self, name):
        self.name = name
    
    @staticmethod
    def statmethod1(x):
        return x
    
    @classmethod
    def classmethod1(cls):
        return cls
    
    @funcattrs(name='GvR', language='python')
    @log(file='func.log')
    def sayhello(self):
        print 'hello python world'
-----
or
-----
class Klass:
    def __init__(self, name):
        self.name = name
    
    def statmethod1(x):
	@staticmethod

        return x
    
    def classmethod1(cls):
	@classmethod

        return cls
    
    def sayhello(self):
	@funcattrs(name='GvR', language='python')
	@log(file='func.log')

        print 'hello python world'
-----

If the decorators are metadata, that may be extended to affect
not only functions or methods, but classes, and modules(?), I would
think that wherever a variable or function call would go that
would affect the function, method, class, or module, is the
right place for a decorator.

In the alternative above, it _may_ be that the decorators would
only be valid if they are located in specific locations, e.g.,
before any non decorator (or comment, or __doc__ information)
statements.

John




More information about the Python-list mailing list