This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author daniel.urban
Recipients daniel.urban, dsdale24
Date 2011-03-20.09:18:51
SpamBayes Score 0.0
Marked as misclassified No
Message-id <>
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/", line 60, in <module>

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, <> 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?
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.
Date User Action Args
2011-03-20 09:18:52daniel.urbansetrecipients: + daniel.urban, dsdale24
2011-03-20 09:18:52daniel.urbansetmessageid: <>
2011-03-20 09:18:52daniel.urbanlinkissue11610 messages
2011-03-20 09:18:51daniel.urbancreate