[PyQt] dip model types, properties, and syntax

[Darren Dale]

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.

Cheers,
Darren