-
Notifications
You must be signed in to change notification settings - Fork 51
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Unify properties getter, setters and deleters under a single documentation entry #587
Comments
This is not valid python, hopefully, so it makes things a bit simpler. class Person:
_name=None
@property
def name(self):
return self._name
@Person.name.setter
def name(self, value):
self._name = value |
But this is valid python: class A:
_data=None
@property
def data(self):
if self._data is None:
self._data = Data(self)
return self._data The thing is the current handling of properties makes us blind to any instance attributes declared in property getters, i.e. we won't not visit the So I think the manner to handle property is to first of all create |
…deleters under a single documentation entry.
So turns out proper support for properties is a bit more complex that I would imagine:
So we can end up with code like: class BaseClass(object):
def __init__(self):
self._spam = 5
@property
def spam(self):
"""BaseClass.getter"""
return self._spam
@spam.setter
def spam(self, value):
self._spam = value
@spam.deleter
def spam(self):
del self._spam
class SubClass(BaseClass):
@BaseClass.spam.getter
def spam(self): # this overrides the getter only of the property and use the inherited functions for the setter and deleter.
"""SubClass.getter"""
... This brings other considerations for pydoctor, like how to present the fact that some parts of the property methods are inherited and some parts not? And this complexifies the AST building part. The simplest thing to do would be to always create a property if some parts of a property are defined, show all property methods, but say which are inherited. |
It would good to see all the information about a property inside a single documentation entry.
The main issue is what to do if several object have docstrings assigned to ? Should they be merge them together? Should we display them in separate boxes?
Or maybe we should log a warning an use only the getter docstring. This would be the most simple solution and also comply with the default behavior of
help()
, but we’ve been using docstring on property setter in our demo. So we should probably look at a way of still supporting that.Anyway the information whether this property is writable or deletable or read only can be added as
extra_info
.The text was updated successfully, but these errors were encountered: