Darren Dale <dsdal...@gmail.com> added the comment: On Sun, Mar 20, 2011 at 5:18 AM, Daniel Urban <rep...@bugs.python.org> wrote: > > 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.
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? ---------- _______________________________________ 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
