On Sun, Mar 20, 2011 at 5:18 AM, Daniel Urban <report@bugs.python.org> wrote:
>
> Daniel Urban <urban.dani+py@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@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.

Unlike methods, properties are composite objects. It is therefore
reasonable that creating an abstract property might be a little
different from creating an abstract method.

> 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).

Thank you for pointing that out. I've followed up with him at
python-ideas to seek clarification (he did not raise this point when I
posted the change to descrobject.c)

>> 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

I'm familiar with that page. Do you know of any documentation
addressing how to anticipate and respond to NULL?