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
Omitting constructor signature from class header using autoclass
#4257
Comments
Unfortunately, there are no way to do that. The +1: I agree that it is valuable if we can show explanations both of the class and |
Can this issue be renamed to smth. like "Omitting constructor signature from class header" ? I had a hard time finding it. |
My use case is documenting a serializer, a class derived from rest_framework.serializers.ModelSerializer.
This class is only constructed by the framework, and never constructed by the user, but in my docs I get
There is no way to remove the constructor signature, which is long, ugly, and totally irrelevant for people reading the docs. |
autoclass
For people coming from Google, I found a workaround that works on Sphinx 1.8 (the default Sphinx on Read the Docs):
This will override the automatic constructor and not render anything, not even the parenthesis. It's still a little ugly and confusing, but works for now. |
I don't think it works in Sphinx 2+ |
- Conceptually, class documentation describes the class usage and `__init__` describes constructor usage. It was previously decided to merge them because having them separated would list their signatures twice. Once in the class description, and once in the `__init__` method. A side-effect of this previous workaround was that the merged content, if `__init__` does not have a docstring, would try to inherit the `__init__` docstring from the parent class. That means suppressing this inheritance would require a vacuous `__init__`. This has to be duplicated in, for example, all unit tests, because they do not require custom constructors. Maintaining this is takes more effort and scaffolding than it is worth. So it is now separated and the signature will be duplicated in the documentation instead, albeit not a desired outcome. Ideally, the class heading would not list the signature. There is an open issue for this. See: <sphinx-doc/sphinx#4257> - Show dunder (and base classes) in documentation This is necessary to show documentation for `__init__` separately, now that it is not included in the class documentation part. As a side-effect, this also shows other custom dunder methods. However, `__dict__`, `__module__` and `__weakref__` are excluded still, as they are not generally useful. - Ignore inherited methods. In particular, do not inherit documentation for the newly shown `__init__`. This is usually undesirable, as the documentations may be third-party, and may break builds if their docstrings are not compatible. Note that this flag does not stop the merged class docstring from inheriting `__init__`, so this alone would not solve the aforementioned issue. - Remove types from signature. This will add parameter and return types into description if the parameters are not there already. Previously, the types are included in the signature, which makes the signature unreadable. This should help with the duplication mentioned above by reducing the duplicated noise a little.
- Conceptually, class documentation describes the class usage and `__init__` describes constructor usage. It was previously decided to merge them because having them separated would list their signatures twice. Once in the class description, and once in the `__init__` method. A side-effect of this previous workaround was that the merged content, if `__init__` does not have a docstring, would try to inherit the `__init__` docstring from the parent class. That means suppressing this inheritance would require a vacuous `__init__`. This has to be duplicated in, for example, all unit tests, because they do not require custom constructors. Maintaining this is takes more effort and scaffolding than it is worth. So it is now separated and the signature will be duplicated in the documentation instead, albeit not a desired outcome. Ideally, the class heading would not list the signature. There is an open issue for this. See: <sphinx-doc/sphinx#4257> - Show dunder (and base classes) in documentation This is necessary to show documentation for `__init__` separately, now that it is not included in the class documentation part. As a side-effect, this also shows other custom dunder methods. However, `__dict__`, `__module__` and `__weakref__` are excluded still, as they are not generally useful. - Ignore inherited methods. In particular, do not inherit documentation for the newly shown `__init__`. This is usually undesirable, as the documentations may be third-party, and may break builds if their docstrings are not compatible. Note that this flag does not stop the merged class docstring from inheriting `__init__`, so this alone would not solve the aforementioned issue. - Remove types from signature. This will add parameter and return types into description if the parameters are not there already. Previously, the types are included in the signature, which makes the signature unreadable. This should help with the duplication mentioned above by reducing the duplicated noise a little.
As a naming suggestion for this option, how about the following name?
or
It would be nice to have the ability to override it with autoclass if needed.
I don't think the |
Add `autodoc_class_signature` to separate the class entry and the definition of `__init__()` method.
Add `autodoc_class_signature` to separate the class entry and the definition of `__init__()` method.
Add `autodoc_class_signature` to separate the class entry and the definition of `__init__()` method.
Add `autodoc_class_signature` to separate the class entry and the definition of `__init__()` method.
Add `autodoc_class_signature` to separate the class entry and the definition of `__init__()` method.
Add `autodoc_class_signature` to separate the class entry and the definition of `__init__()` method.
Add `autodoc_class_signature` to separate the class entry and the definition of `__init__()` method.
Close #4257: autodoc: Add autodoc_class_signature
I'm a bit surprised to see that (in the Python domain)
will create a heading like
class Foo(*args)
which seems quite unintuitive to me, as it mixes two concepts: the declaration of "class Foo", with a constructor call "Foo(*args)". How can I suppress the (automatic) addition of the constructor signature to the generated heading ?I actually want to document the constructor with an additional nested
.. automethod::
directive, and I also have an overloaded__call__
method, making the above all the more confusing.Am I missing or misunderstanding something ?
The text was updated successfully, but these errors were encountered: