Since v0.17, docutils starts to load language module on parsing reST
document using StateMachine directly. So far, our testcase uses invalid
language code for testing autosummary. This fixes it to work with new
docutils.
Since v0.17, docutils starts to use <figure> and <figcaption> for figure
and its caption on HTML output. This modifies the expected value of our
testcases to support it.
Add new tests to exercise the new autodoc_typehint_undoc option. Where
an existing test would have a meaningful behavior change with the new
option set to False, that test is copied, the new option is set to False
in the copy, and the assertions reflect the new expected behavior.
The new test test_autodoc_typehints_description_with_documented_init
illustrates the problem reported in #7329, and the new test
test_autodoc_typehints_description_with_documented_init_no_undoc
illustrates that this issue no longer occurs when the new
autodoc_typehint_undoc option is set to False.
Previously, `__init__` type hints were not used when documenting a class
using `autodoc_typehints="description"`. This was done to prevent
documentation for parameters from showing up twice, both for the class
and the `__init__` special method. As the new ``autodoc_typehint_undoc``
option provides a better way to prevent this bad behavior by placing the
user in control of where the type hints are added, it is now safe to add
type hints for documented `__init__` parameters.
Closes#8178
Previously, if autodoc_typehints="description", a :type: field would be
added for every parameter and return type appearing in the annotation,
including **kwargs and underscore-prefixed parameters that are meant to
be private, as well as None return types.
This commit introduces a new option, "autodoc_typehint_undoc". By
default this option is True, requesting the old behavior. By setting
this option to False, :type: and :rtype: fields will only be added for
annotated parameters or return types if there is already a corresponding
:param: or :return: field, to put users in control over whether a given
parameter is documented or not.
This generates `:canonical:` option for `:py:class:` directive if the
target class is imported from other module. It allows users to refer it
using both the new name (imported name) and the original name (canonical
name).
It helps a library that implements some class in private module (like
`_io.StringIO`), and publish it as public module (like `io.StringIO`).
