[Python-ideas] Would it possible to define abstract read/write properties with decorators?

[Guido van Rossum]

It looks like you have moved on to a different strategy; let me
comment on the code review instead.

On Sun, Mar 20, 2011 at 7:06 AM, Darren Dale <dsdale24 at gmail.com> wrote:
> On Sat, Mar 19, 2011 at 12:24 PM, Guido van Rossum <guido at python.org> wrote:
>> Thanks much for your contribution! In order to get it reviewed and
>> submitted, can you please create a bug for this issue (mention the
>> python-ideas thread), upload your patch there, and perhaps ping
>> python-dev?
>
> I did so, at http://bugs.python.org/issue11610 . The first reviewer
> directed me to discussion concerning the implementation of abstract
> classmethods at http://bugs.python.org/issue5867 . In that case, you
> objected to extending the implementation of classmethod to allow
> assigning to an __isabstractmethod__ attribute, which would have
> allowed the same syntax I suggested, combining @abstractmethod and
> @classmethod. The patch I made (which doesn't work yet) also attempts
> to extend the implementation of a builtin. Do you still object to this
> approach? There are two somewhat related issues:
>
> * api: The first reviewer objects to using a single decorator for
> methods (regular, class, and static) but a combination of two
> decorators for properties.
> * implementation: The current abc.abstractproperty has some issues
> beyond not supporting the decorator syntax, which are due to the fact
> that properties are composite objects, and it is the methods which
> compose the property that should imbue "abstractness".
>  - To provide an implementation for an abstract property, one
> currently has to completely respecify a concrete property and rebind
> it. If an ABC defines an abstract read/write property and a subclass
> mistakenly redefines it as a read-only property, the ABC mechanisms
> will not catch the error.
>  - I can imagine cases where an abstract base class may define a
> simple concrete getter but an abstract setter. This is not possible
> with the current abstractproperty.
>  - An abstractproperty cannot be made concrete through the use of the
> decorators:
>
>    class D(MyABC):
>        @MyABC.my_abstract_property.setter
>        def my_abstract_property(self):
>            ...
>
> because @MyABC.my_abstract_property.setter returns another instance of
> abstractproperty.
>
> I think the general approach I suggested resolves all of these issues.
> If you have reservations about extending builtins, an alternative
> might be to improve the definition of abstractproperty so it supports
> the features and addresses the issues we have been discussing, and has
> decorators implemented such that once all of the abstract methods have
> been replaced with concrete ones, they return an instance of the
> built-in property rather than abc.abstractproperty. Does this sound
> like it could be an acceptable alternative?
>
> Darren
>



-- 
--Guido van Rossum (python.org/~guido)