¿Cómo usar el autodoc de Sphinx para documentar el método __init __ (auto) de una clase?

Sphinx no genera documentos para __init __ (auto) de forma predeterminada. He probado lo siguiente:

.. automodule:: mymodule :members: 

y

 ..autoclass:: MyClass :members: 

En conf.py, configurar lo siguiente solo agrega la cadena de documentación __init __ (auto) a la cadena de documentación de la clase ( la documentación del autodoc de Sphinx parece estar de acuerdo en que este es el comportamiento esperado, pero no menciona nada con respecto al problema que estoy tratando de resolver):

 autoclass_content = 'both' 

Aquí hay tres alternativas:

  1. Para asegurarse de que __init__() esté siempre documentado, puede usar autodoc-skip-member en conf.py. Me gusta esto:

     def skip(app, what, name, obj, would_skip, options): if name == "__init__": return False return would_skip def setup(app): app.connect("autodoc-skip-member", skip) 

    Esto define explícitamente que __init__ no se debe omitir (lo cual está predeterminado). Esta configuración se especifica una vez y no requiere ningún marcado adicional para cada clase en la fuente .rst.

  2. La opción de special-members se agregó en Sphinx 1.1 . Hace que los miembros “especiales” (aquellos con nombres como __special__ ) sean documentados por autodoc.

    Desde Sphinx 1.2, esta opción toma argumentos que la hacen más útil de lo que era anteriormente.

  3. Utilice automethod :

     .. autoclass:: MyClass :members: .. automethod:: __init__ 

    Esto se debe agregar para cada clase (no se puede usar con automodule , como se señaló en un comentario a la primera revisión de esta respuesta).

Estabas cerca Puede usar la opción autoclass_content en su archivo conf.py :

 autoclass_content = 'both' 

En los últimos años he escrito varias variantes de autodoc-skip-member de autodoc-skip-member de autodoc-skip-member para varios proyectos de Python no relacionados porque quería que métodos como __init__() , __enter__() y __exit__() aparecieran en la documentación de mi API (después de todo, estos los “métodos especiales” son parte de la API y qué mejor lugar para documentarlos que dentro de la cadena de documentación del método especial).

Recientemente tomé la mejor implementación y la hice parte de uno de mis proyectos de Python ( aquí está la documentación ). La implementación básicamente se reduce a esto:

 def enable_special_methods(app): """ Enable documenting "special methods" using the autodoc_ extension. :param app: The Sphinx application object. This function connects the :func:`special_methods_callback()` function to ``autodoc-skip-member`` events. .. _autodoc: http://www.sphinx-doc.org/en/stable/ext/autodoc.html """ app.connect('autodoc-skip-member', special_methods_callback) def special_methods_callback(app, what, name, obj, skip, options): """ Enable documenting "special methods" using the autodoc_ extension. Refer to :func:`enable_special_methods()` to enable the use of this function (you probably don't want to call :func:`special_methods_callback()` directly). This function implements a callback for ``autodoc-skip-member`` events to include documented "special methods" (method names with two leading and two trailing underscores) in your documentation. The result is similar to the use of the ``special-members`` flag with one big difference: Special methods are included but other types of members are ignored. This means that attributes like ``__weakref__`` will always be ignored (this was my main annoyance with the ``special-members`` flag). The parameters expected by this function are those defined for Sphinx event callback functions (ie I'm not going to document them here :-). """ if getattr(obj, '__doc__', None) and isinstance(obj, (types.FunctionType, types.MethodType)): return False else: return skip 

Sí, hay más documentación que lógica :-). La ventaja de definir una autodoc-skip-member como esta sobre el uso de la opción de special-members (para mí) es que la opción de special-members también permite la documentación de propiedades como __weakref__ (disponible en todas las clases de nuevo estilo, AFAIK) ) que considero ruido y nada útil. El enfoque de callback evita esto (porque solo funciona en funciones / métodos e ignora otros atributos).