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

[Darren Dale]

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