[Python-Dev] Property syntax (Re: [Python-Dev] Extended Function
syntax)
Shane Holloway (IEEE)
shane.holloway@ieee.org
Fri, 31 Jan 2003 00:32:34 -0700
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