[PyQt] dip model types, properties, and syntax

[Phil Thompson]

On Wed, 25 Aug 2010 14:27:55 -0400, Darren Dale <dsdale24 at gmail.com>
wrote:
> On Wed, Aug 25, 2010 at 1:17 PM, Phil Thompson
> <phil at riverbankcomputing.com> wrote:
>> On Sat, 14 Aug 2010 08:45:13 +0100, Phil Thompson
>> <phil at riverbankcomputing.com> wrote:
>>> On Mon, 9 Aug 2010 09:45:12 -0400, Darren Dale <dsdale24 at gmail.com>
>> 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