`typing.get_type_hints()` raises NameError when the target object
contains unresolavable type annotation (ex. TYPE_CHECKING). This
handles the exception and use unresolved annotations for type hints.
An annotated instance variable on super class is not documented when
derived class has also other annotated instance variables because
`obj.__annotations__` is overrided by derived class's type hints.
To get annotations of the target class correctly, this scans MRO to
get all of annotated instance variables.
So far, autodoc treats a "private" class attribute as a mere attribute.
But its name is mangled by python interpreter. This make it unmangled
name to be documented expectedly.
So far, type annotations for overloaded functions are not resolved
because they are obtained from AST directly. This tries to evaluate
them using a context of its function or method.
This fixes:
* Signatures defined by __new__
* Signatures defined by metaclasses
* Signatures defined by builtin base classes
All of these changes bring the sphinx docs inline with the behavior of `inspect.signature`.
Note that this changes autodoc to output `.. py:class: MyClass()` with parentheses even if no user-defined __init__ is present.
This is quite deliberate, as if no user-defined `__init__` is present the default is `object.__init__`, which indeed does not take arguments.
This `if not self._datadescriptor` was originally here before type annotations were supported, to prevent showing `descr4 = <_Descriptor ...>` in the docs.
When type annotations were added, the support for appending `:type:` was put in the wrong place.
It should have been outside this if, not within it.
A common use case for this is a class like `namedtuple`, which has a public `_replace` method that is so-named in order not to conflict with arbitrary user-provided attributes.
Rejected spellings include:
* `:meta not-private:`
* `:meta private: False`
If a singledispatch function has its `__signature__` rewritten, autodoc
fails to annotate that signature because `func.__annotations__` is not
consulted. Instead, directly assign to `__signature__` instead.
Functions that are decorated with `@lru_cache` or other `functools`
decorators may not even be detected as a function. This results in the
documentation not having the `()` or even trying to render the function
signature.
This change updates the `sphinx.util.inspect` code to unwrap
`__wrapped__` functions before determining if they can be documented.
`@lru_cache` and its associated test is an example of a decorated
function that is incorrectly identified as an attribute rather than a
module level function and when rendering the signature (upon changing
`isattributedescriptor`) the decorated function is still incorrectly
identified as a C function.
This change also renames the newly introduced `unwrap` as `unwrap_all`
because it is different than the prexisting Python supplied
`inspect.unwrap`.
See `update_wrapper` "Changed in version 3.4" for more background:
https://docs.python.org/3/library/functools.html#functools.update_wrapper
There were two used:
- print_function
- absolute_import
Both of these are mandatory in Python 3.0 onwards [1] and can therefore
be removed...mostly. Unfortunately, mypy is still running in Python 2.7
mode, meaning we need the 'print_function' future wherever we're calling
'print' with the 'file' argument. There's also a single
'absolute_import' future that must be retained as its removal breaks a
test for as-yet unknown reasons. TODOs are added to resolve both issues
in the future.
[1] https://docs.python.org/3/library/__future__.html
Signed-off-by: Stephen Finucane <stephen@that.guru>
Previously, users could specify a *list* of flags in their config files.
The flags were directive names that would otherwise be present in the
.rst files. However, as a list, it was not possible to specify values
to those flags, which *is* possible in .rst files.
For example, in .rst you could say
:special-members: __init__, __iter__
And this would cause autodoc to generate documents for these methods that
it would otherwise ignore.
This commit changes the config option to instead accept a dictionary.
This is a dictionary whose keys can contain the same flag-names as before,
but whose values can contain the arguments as seen in .rst files.
The old list is still supported, for backwards compatibility, but the data
is transformed into a dictionary when the user's config is loaded.
