Daniel Urban <urban.dani...@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, <dsdal...@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 <rep...@bugs.python.org> <http://bugs.python.org/issue11610> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
