Chilipp / autodocsumm

Extending your autodoc API docs with a summary
Apache License 2.0
48 stars 14 forks source link

Order in class is random #14

Closed maeddlae closed 4 years ago

maeddlae commented 5 years ago

The order of class docstring, __init__(if autoclass_content = "both" in conf.py) and autodocsumm summary is not always the same. For example

class A():
    """  
    Summary line

    Blubliblalblablalbalblablalb

    **Example**

    .. code-block:: python

        blie = A()
        blie.meth_1(2)
    """
    CLASS_ATTRIBUTE = 1 #: class attribute

    def __init__(self):
        """
        This is the __init__ docstring

        :param Fruit fruit: param line for sphinx autodoc
        """
        self.object_attribute = "jaja" #: this is an object attribute

    def meth_1(self, a):
        """
        method docstring

        :param int a: blublu
        :return: x is blibli        
        """
        return a + 1

shows class docstring first, then autodocsumm followed by __init__. But

class B(A):
    """
    class B summary
    """
    CLASS_ATTRIBUTE_B = 1 #: class attribute of class b

    def __init__(self):
        """
        This is the init docstring

        :param Fruit fruit: param line for sphinx autodoc
        """
        self.object_attribute_b = "jaja" #: this is an object attribute of class b

    def meth_2(self, a):
        """
        method b docstring

        :param int a: blublu b 
        :return: x is blibli b    
        """
        return a + 1

gives you class docstring first, then __init__ and finally autodocsumm. This is maybe a bug not only concerning autodocsumm but also autodoc from Sphinx. However, it would be nice if the order is always the same and if the user can define it optionally.

maeddlae commented 5 years ago

Update: In this example, the autodocsumm part splits the docstring into two parts!?

from detpack.utils.class_a import A

class B(A):
    """
    class B summary

    This is class B description

    **Example**

    .. code-block:: python

        b = B()
        b.meth_1(2)

    bliblu

    This this this
    """
    CLASS_ATTRIBUTE_B = 1 #: class attribute of class b

    def __init__(self):
        """
        This is the init docstring

        :param Fruit fruit: param line for sphinx autodoc
        """
        self.object_attribute_b = "jaja" #: this is an object attribute of class b

    def meth_2(self, a):
        """
        method b docstring

        :param int a: blublu b 
        :return: x is blibli b    
        """
        return a + 1
Chilipp commented 5 years ago

Hi @maeddlae! Thanks for reporting this! It is not random in that sense, but it is not solved very well, I totally agree. The problem is, that autodocsumm has to insert the summary somewhere without knowing the exact documentation. There are some criteria (see https://github.com/Chilipp/autodocsumm/blob/520d1e72079d894fa63556d1cd192456c922e36d/autodocsumm/__init__.py#L490) but I see that they fail in your case. At the moment this insertion is rather something that is put on top of the generated nodes because then we do not have to replicate the code of autodoc. Maybe the functionality of the autodocsumm package should be implemented directly into the sphinx autodoc extension via PR. I'll have a look into this within the next days.

maeddlae commented 5 years ago

Ok, thanks for investigating that:-)

Chilipp commented 4 years ago

@maeddlae, the docstring is now always behind the docstring as I avoid this injection of the doc_nodes now

Chilipp commented 4 years ago

Just a quick update: With #29 you can now also specify the exact positioning of the summary by adding the .. autoclasssumm directive in a class docstring, see https://autodocsumm.readthedocs.io/en/latest/examples.html#positioning-of-the-autosummary-table