On Wed, Sep 15, 2010 at 8:12 AM, Matti Airas <[email protected]> wrote:
> Hi,
>
> Darren Dale suggested a few days ago using a decorator syntax for declaring
> Qt properties. Since that sounded like such an awesome idea, I'd like to
> discuss it a bit further.
>
> Having not that much experience with Qt properties, do you think the
> decorator syntax could be just:
>
> class C(object):
> �[email protected]
> def x(self):
> return self._x
>
> �[email protected]
> def x(self, value):
> self._x = value
>
> �[email protected]
> def x(self):
> del self._x
>
> That is, the only difference to Python property decorators [1] would be that
> instead of @property you'd have @QtCore.Property.
>
> Would that work in practice? How about the implementation: is there going to
> be a clash with PSEP 103 [2]?
Maybe not...
> Just mimicking Python's native property decorators would leave many of the
> arguments in PSEP 103 out of reach.
I think a slight change of syntax may be necessary, see below.
> The freset argument would be easy - just
> define an @x.resetter decorator. How about all of the other arguments,
> taking non-function values? What would be a a clean, consistent syntax for
> defining them?
One could insist Property be called with a type or string as the first
argument, see below. Property.__new__ might be implemented to raise an
error if it receives a function as the first argument. In order to
improve the syntax, you might implement Property.__call__ to defer to
the getter:
class C(object):
_x = None
_y = None
# this is better than @QtCore.Property(int, **kwargs).getter:
@QtCore.Property(int, **kwargs)
def x(self):
return self._x
y = QtCore.Property(int, **kwargs)
@y.getter
def y(self):
return self._y
Just a suggestion.
Darren
_______________________________________________
PySide mailing list
[email protected]
http://lists.openbossa.org/listinfo/pyside
