Skip to content
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

missing docstrings of methods #426

Open
emanueleromito opened this issue Jul 5, 2023 · 3 comments
Open

missing docstrings of methods #426

emanueleromito opened this issue Jul 5, 2023 · 3 comments
Labels
bug Something isn't working help wanted Extra attention is needed

Comments

@emanueleromito
Copy link

emanueleromito commented Jul 5, 2023

Hi guys. Thanks for releasing and mantaining pdoc.

In my codebase, I have a class that inherits from an abstract class, and within this derived class, I have methods named "compute" that are decorated or modified by a wrapper. However, when generating the HTML documentation using pdoc, I noticed that the docstrings associated with these "compute" methods are missing in the generated documentation.

I have verified that the docstrings are present in the source code and are correctly formatted. However, they are not appearing in the generated HTML documentation. This issue seems to be specific to the "compute" methods within the derived class, as the docstrings for other methods are being displayed correctly.

@misanthropicat
Copy link

Have the same problem: any decorated method of any class inherited from abstract object has missing docstrings in generated HTML documentation. Any plans to fix it?

@thatdc-reply
Copy link

I am having the same issue: any method decorated with @ is omitted in the documentation

@kernc
Copy link
Member

kernc commented Jun 24, 2024

The behavior is based on this logic:

pdoc/pdoc/__init__.py

Lines 1045 to 1059 in d1136ea

public_objs = []
for _name, obj in _getmembers_all(self.obj):
# Filter only *own* members. The rest are inherited
# in Class._fill_inheritance()
if ((_name in self.obj.__dict__ or
_name in annotations) and
(_is_public(_name) or
_is_whitelisted(_name, self))):
if _is_blacklisted(_name, self):
self.module._context.blacklisted.add(f'{self.refname}.{_name}')
continue
obj = inspect.unwrap(obj)
public_objs.append((_name, obj))

pdoc/pdoc/__init__.py

Lines 993 to 1018 in d1136ea

def _getmembers_all(obj: type) -> List[Tuple[str, Any]]:
# The following code based on inspect.getmembers() @ 5b23f7618d43
mro = obj.__mro__[:-1] # Skip object
names = set(dir(obj))
# Add keys from bases
for base in mro:
names.update(base.__dict__.keys())
# Add members for which type annotations exist
names.update(getattr(obj, '__annotations__', {}).keys())
results = []
for name in names:
try:
value = getattr(obj, name)
except AttributeError:
for base in mro:
if name in base.__dict__:
value = base.__dict__[name]
break
else:
# Missing slot member or a buggy __dir__;
# In out case likely a type-annotated member
# which we'll interpret as a variable
value = None
results.append((name, value))
return results

I don't know if it solves it, but now that inspect.getmembers_static() is available, we should probably see to using that instead of the above custom logic. Can somebody try it?

@kernc kernc added bug Something isn't working help wanted Extra attention is needed labels Nov 25, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working help wanted Extra attention is needed
Development

No branches or pull requests

4 participants