[PyQt] dip model types, properties, and syntax

[Darren Dale]

On Sat, Aug 14, 2010 at 8:25 AM, Darren Dale <dsdale24 at gmail.com> wrote:
> On Sat, Aug 14, 2010 at 3:45 AM, 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.
>
> Defining new getters and setters for inherited properties would also
> be more verbose:
>
> class ExampleModel2(ExampleModel)
>
>    # either:
>    #@ExampleModel.name.getter
>    # or:
>    @super(ExampleModel2, ExampleModel2).name.getter
>    def name(self):
>        return self._name
>
> but then again, I might argue that it is more clear from an api standpoint.

I should have tested more carefully. @super(ExampleModel2,
ExampleModel2) will not work inside the class definition unless it
appears in a method, where it will only be called after an
ExampleModel2 class has already been defined. So overriding property
getters, setters, and friends might look like:

class ExampleModel2(ExampleModel):

    @ExampleModel.name.getter
    def name(self):
        return self._name

    # that redefines the property and binds it in the
    # current namespace. So now we should use the
    # name property from the current namespace:
    @name.setter
    def name(self, val):
        self._name = val

Darren