Greg Ewing wrote:
def foo as property: def __get__(self): ... def __set__(self, x): ...
The above syntax seems to be particularly easy to read and understand, and that is a Good Thing. ;) If I understand it correctly, here is a longer sample::
class Fun(object): def origonal(self, a, b): return a * b
def foo(self, a, b) as method: return a + b
def bar(klass, a, b) as classmethod: return klass(a, b)
def push(self, item) as sync_method: self._queue.append(item)
def pop(self) as sync_method: self._queue.pop()
def circumference as property: """Property docstring""" def __get__(self): return self.radius*6.283 def __set__(self, value): self.radius = value/6.283 def __delete__(self): del self.radius
Similar to Guido's behind-the-scenes implementation peak::
def v(a0, a1, a2) as e: S
T = <a thunk created from S> v = e(T)
v(a0, a1, a2) # would be the same as e(T).__call__(a0, a1, a2)
Seems very clean and extensible since 'e' can interpret the thunk 'T' as it sees fit. If the implementation chooses to execute the thunk and pull the __get__/__set__/__delete__ methods to implement a property, it can. In the same way, a different implementation may choose to execute 'T' as a code block when called, perhaps modifying the parameter list.
Issues-that-will-steal-my-sleep-tonight: * The scoping issues seem very hairy. * The definition of what the thunk is remains nebulas. * Additional parameters for 'e' in the 'e(T)' would be *very* useful. * This syntax does not address the inline semantics (and potential usefulness!) of Guido's proposal::
> foo = property: > ...
Even with all these outstanding issues, the potentials start to tantalize the imagination! -Shane Holloway