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

Omitting constructor signature from class header using autoclass #4257

Closed
stefanseefeld opened this issue Nov 22, 2017 · 6 comments
Closed
Labels
Milestone

Comments

@stefanseefeld
Copy link

I'm a bit surprised to see that (in the Python domain)

.. autoclass:: Foo
   ...

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 ?

@tk0miya
Copy link
Member

tk0miya commented Aug 26, 2018

Unfortunately, there are no way to do that. The autoclass directive always shows its signature automatically.

+1: I agree that it is valuable if we can show explanations both of the class and __init__() method independently.

@tk0miya tk0miya added this to the 2.0.0 milestone Aug 26, 2018
@earshinov
Copy link

Can this issue be renamed to smth. like "Omitting constructor signature from class header" ? I had a hard time finding it.

@earshinov
Copy link

My use case is documenting a serializer, a class derived from rest_framework.serializers.ModelSerializer.

class OrderSerializer(serializers.ModelSerializer):
  ...

This class is only constructed by the framework, and never constructed by the user, but in my docs I get

class OrderSerializer(instance=None, data=<class 'rest_framework.fields.empty'>, **kwargs)
  ...

There is no way to remove the constructor signature, which is long, ugly, and totally irrelevant for people reading the docs.

@stefanseefeld stefanseefeld changed the title correct usage of autoclass directive Omitting constructor signature from class header using autoclass Jan 17, 2019
@tk0miya tk0miya modified the milestones: 2.0.0, 2.1.0 Feb 15, 2019
@tk0miya tk0miya modified the milestones: 2.1.0, 2.2.0 Jun 2, 2019
@tk0miya tk0miya modified the milestones: 2.2.0, 2.3.0 Aug 18, 2019
@tk0miya tk0miya modified the milestones: 2.3.0, 2.4.0 Dec 8, 2019
@tk0miya tk0miya modified the milestones: 2.4.0, 3.0.0 Feb 7, 2020
@tk0miya tk0miya modified the milestones: 3.0.0, 3.1.0 Mar 14, 2020
@tk0miya tk0miya modified the milestones: 3.1.0, 3.2.0 Jun 4, 2020
@tk0miya tk0miya modified the milestones: 3.2.0, 3.3.0 Aug 2, 2020
@J-M0
Copy link

J-M0 commented Sep 16, 2020

For people coming from Google, I found a workaround that works on Sphinx 1.8 (the default Sphinx on Read the Docs):

.. autoclass:: Foo()

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.

@fjarri
Copy link
Contributor

fjarri commented Sep 17, 2020

I don't think it works in Sphinx 2+

BoniLindsley added a commit to BoniLindsley/phile that referenced this issue Oct 26, 2020
-   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.
BoniLindsley added a commit to BoniLindsley/phile that referenced this issue Oct 29, 2020
-   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.
@tk0miya tk0miya modified the milestones: 3.3.0, 3.4.0 Nov 1, 2020
@tk0miya tk0miya removed this from the 3.4.0 milestone Dec 19, 2020
@tk0miya tk0miya added this to the 3.5.0 milestone Dec 19, 2020
@tk0miya tk0miya modified the milestones: 3.5.0, 4.0.0 Feb 14, 2021
@shimizukawa
Copy link
Member

shimizukawa commented Mar 27, 2021

As a naming suggestion for this option, how about the following name?

autoclass_signature = "mixed"  # default
autoclass_signature = "separated"  # new

or

autodoc_default_options = {
    "class-signature": "mixed",  # default
    "class-signature": "separated",  # new
}

It would be nice to have the ability to override it with autoclass if needed.

.. autoclass:: OrderSerializer
  :class-signature: separated

I don't think the autodoc_default_options or overrides by autoclass are necessary, so I think autoclass_signature is fine.

@tk0miya tk0miya modified the milestones: 4.0.0, 4.1.0 Apr 11, 2021
tk0miya added a commit to tk0miya/sphinx that referenced this issue May 5, 2021
Add `autodoc_class_signature` to separate the class entry and the
definition of `__init__()` method.
tk0miya added a commit to tk0miya/sphinx that referenced this issue May 6, 2021
Add `autodoc_class_signature` to separate the class entry and the
definition of `__init__()` method.
tk0miya added a commit to tk0miya/sphinx that referenced this issue May 6, 2021
Add `autodoc_class_signature` to separate the class entry and the
definition of `__init__()` method.
tk0miya added a commit to tk0miya/sphinx that referenced this issue May 6, 2021
Add `autodoc_class_signature` to separate the class entry and the
definition of `__init__()` method.
tk0miya added a commit to tk0miya/sphinx that referenced this issue May 15, 2021
Add `autodoc_class_signature` to separate the class entry and the
definition of `__init__()` method.
tk0miya added a commit to tk0miya/sphinx that referenced this issue May 15, 2021
Add `autodoc_class_signature` to separate the class entry and the
definition of `__init__()` method.
tk0miya added a commit to tk0miya/sphinx that referenced this issue May 15, 2021
Add `autodoc_class_signature` to separate the class entry and the
definition of `__init__()` method.
tk0miya added a commit that referenced this issue May 15, 2021
Close #4257: autodoc: Add autodoc_class_signature
@github-actions github-actions bot locked as resolved and limited conversation to collaborators Jul 10, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Projects
None yet
Development

No branches or pull requests

6 participants