A decorator syntax not yet mentioned (I think!)

paolo veronelli paolo_veronelli at yahoo.it
Thu Aug 12 21:52:38 CEST 2004


On Thu, 12 Aug 2004 13:32:32 -0400, Peter Hansen <peter at engcorp.com> wrote:

> paolo veronelli wrote:
>
>> On Wed, 11 Aug 2004 11:40:32 -0400, Peter Hansen <peter at engcorp.com> 
>> wrote:

>> class Klass:
>>     def meth0(x):
>>         return x
>>     mutate meth0:
>>         staticmethod
>>
>> mutate Klass.meth0:
>>     debugged
>>
>> reads good to me.
>
> This has the disadvantage of repeating the function name.  I know
> you call it an advantage...  but arguably the biggest part of
> the whole decorator "argument" revolves around whether or not
> it's critical to put the decorator right up above the "def" so
> that it can't be missed.  If the method you describe above was
> deemed acceptable, then I think we'd be sticking with the
> current approach that just reads "func = decorate(func)".

This 'old' method doesn't allow to prepone it,I think a statement was the 
way to allow this ,but why impone it?

class Klass:
	mutate meth0:
		staticmethod
	def meth0(x):
		return x

is acceptable but accept everywhere statements like

@staticmethod Klass.meth0

is the minimum on the pythonic way.
	
	Paolino


-- 
....lotta dura  per la verdura




More information about the Python-list mailing list