[issue11610] Improving property to accept abstract methods

[Daniel Urban]

Daniel Urban <urban.dani+py at gmail.com> added the comment:

I tried to test your patch, but the build dies with this error:
Fatal Python error: Py_Initialize: can't initialize sys standard streams
Traceback (most recent call last):
  File ".../cpython/Lib/io.py", line 60, in <module>
Aborted

I don't know why is this, but I get this error consistently with your patch, and no error without the patch.

On Sat, Mar 19, 2011 at 22:13, <dsdale24 at gmail.com> wrote:
> Thank you for the feedback. The reason I suggested deprecating
> abstractproperty is that I think it is essentially broken. Subclasses
> have to redeclare the entire property, and if they forget to declare
> the setter for what is supposed to be a read/write property, there is 
> no way to catch it. With the new approach, it is possible to ensure
> that all the required features of the property have been implemented.
...
> On 2011/03/19 21:36:09, durban wrote:
> > I don't think abstractproperty should be deprecated. It is still
> > perfectly good to define a read-only abstract property (with one 
> > decorator instead of two).
>
> Zen of python.

I'm guessing you're referring to "There should be one-- and preferably only one --obvious way to do it."  That is a good point.  But currently the one way to:
- create an abstract static method: @abstractstaticmethod
- create an abstract class method: @abstractclassmethod
- create an abstract property: @abstractproperty (as you pointed out, this has some problems)

With your proposed change the one way to:
- create an abstract static method: @abstractstaticmethod
- create an abstract class method: @abstractclassmethod
- create an abstract property: @abstractmethod + @property
This is not a very good API.
Note, that a similar thing could be done for class/staticmethod, and then using @abstractmethod + @classmethod would be possible, and the API would be more consistent.  But it wasn't done because Guido objected it (see issue5867).

> This is the part where I am weak. Can you point me to documentation? 
> Why is an exception check necessary? Do PyObject_IsTrue and Py_DECREF 
> not know what to do when passed NULL?

http://docs.python.org/dev/py3k/c-api/object.html#PyObject_GetAttrString
If a Python API function returns NULL, that usually means that an exception was raised.  If you don't want the exception to propagate, you should call PyErr_Clear.  And I think it is not a good idea to call a function with NULL, unless the docs explicitly say that it can be passed NULL.

----------
components: +Interpreter Core

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11610>
_______________________________________