@decorator syntax is sugar, but for what exactly?

[Avner Ben]

Scott David Daniels wrote:
> ...
> classmethod and staticmethod were introduced some time ago, to provide
> a mechanism for getting to such effects.  At the time there was no clear
> syntax to use that "felt right."  In the meantime people have used these
> features to good effect despite the clunky way you used them.  At this
> point there would probably be a small riot (or at least a large whine)
> if these two were removed.
> ...

The "property" call resembles both classmethod, staticmethod and 
instancemethod, but cannot be eliminated using the new function 
decorator syntax, because of its m:1 nature  - one property binds 
together a getter, a setter etc., where staticmethod etc. change the 
status of one function in one way.

So, if the problem is to rid class definitions of bizarre function 
calls, stuck in the middle of nowhere, that actually add to the 
structure of the class (and which other OO languages solve by legitimate 
syntax), I am dissapointed to observe that functuion decorators do not 
do a complete job after all.

Talking about properties, I like the C# way of defining them, which is 
straightforward and readable. The property begins like a method, but has 
no argument list and includes a getter function with no arguments and a 
setter function with one argument. Adapted to Python, it would look 
something like:

class hasProperty:
	def __init__(self,aProperty='')
		self.aProperty = aProperty
	def AProperty:
		def get(self):
			return self.aProperty
		def set(self,value):
			self.aProperty = value
obj = hasProperty()
obj.AProperty = 'test'
print obj.AProperty