On Wed, 25 Aug 2010 14:27:55 -0400, Darren Dale <[email protected]> wrote: > On Wed, Aug 25, 2010 at 1:17 PM, Phil Thompson > <[email protected]> wrote: >> On Sat, 14 Aug 2010 08:45:13 +0100, Phil Thompson >> <[email protected]> wrote: >>> On Mon, 9 Aug 2010 09:45:12 -0400, Darren Dale <[email protected]> >> wrote: >>>> I have a question about using dip model attributes as properties. The >>>> documentation at >>>> >>> >> http://www.riverbankcomputing.com/static/Docs/dip/model_tutorial.html#attributes-are-properties >>>> gives an example: >>>> >>>> class ExampleModel(Model): >>>> >>>> name = Str >>>> >>>> def _get_name(self): >>>> return self._name >>>> >>>> def _set_name(self, value): >>>> self._name = value >>>> >>>> # method taken from previous section in documentation: >>>> def _default_name(self): >>>> import name_database >>>> return name_database.most_common_name() >>>> >>>> >>>> Would it be possible for dip's model types to support the property >>>> decorator syntax introduced in Python-2.6? If so, the above example >>>> could then be implemented as: >>>> >>>> class ExampleModel(Model): >>>> >>>> name = Str >>>> >>>> @name.getter >>>> def name(self): >>>> return self._name >>>> >>>> @name.setter >>>> def name(self, value): >>>> self._name = value >>>> >>>> @name.default >>>> def name(self): >>>> import name_database >>>> return name_database.most_common_name() >>>> >>>> The virtue, aside from reusing an already familiar pattern in the >>>> standard library, is that the ExampleModel namespace has fewer exposed >>>> private methods, which is desirable for models intended to be used and >>>> inspected in an interactive python environment like IPython. >>> >>> Hmm - interesting. It's more verbose but it is nicer. It could also >>> support observers and allow declarative observers across classes. It may >>> also be faster. >> >> Unfortunately I can't think of a way to implement it. The problem arises >> because "name = Str" is allowed as a shortcut for "name = Str()" and >> there >> doesn't seem to be a way to implement (for example) getter() so that it >> can >> cope with the different cases. > > Hmm. What if BaseType or ValueType did something like: > > @classmethod > def property(cls, val): > if type(val) == types.FunctionType: > return property_factory(cls, getter=val) > else: > res = property_factory(cls, default=val) > return res.getter > > That may let you do: > > class Test(model): > @Str.property > def name(self): > return self._name > > or > > class Test(model): > #provide the default: > @Str.property('foo') > def name(self): > return self._name > > Is that a crazy idea?
I don't like it because it doesn't follow the "standard" pattern you first mentioned. If we have to come up with a new pattern then I think the current one is better. Phil _______________________________________________ PyQt mailing list [email protected] http://www.riverbankcomputing.com/mailman/listinfo/pyqt
