tweaking @decorator syntax - yet another syntax

[Stefan Eischet]

Hi,

I don't know if this particular syntax has been discussed already... 
please feel free to bash me if it was. ;-)

How about using "is" after the def?

class spam(object):

     def ni(self) is classmethod: # takes a decorator
         pass

     def foo(self) is (classmethod, synchronized): # or a tuple of 
decorators
         pass

	combination = (classmethod, strange, very_long_description,
                    wraps_nicely, blah_blah)

     def bar(self) is spam.combination: # another tuple of decorators
         pass

     def bar2(self) is spam.combination:
         pass

I think this is quite easy to read and, in comparison to other 
techniques, allows you to first define 'types' of decorated functions 
(like spam.combination or perhaps (Win32API, lives_in_a_dll,)). I have 
no idea if it can be easily implemented, though.

Regarding the original post below, concerning decorated classes:

superuseful = (gives_milk, mows_your_lawn, pays_your_rent)

class foobar(spam) is superuseful:
     pass

Just my 2 cents.

Cheers,
   Stefan Eischet

On 05.08.2004, at 16:17, John Marshall wrote:

> 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
>
> -- 
> http://mail.python.org/mailman/listinfo/python-list
>
>
// stefan at eischet.com //