To support creating hyperlinks to container types naturally, py domain
should take fully-qualified typehints for them. But nobody wants to
show "typing." module name on the signature. So this suppresses them
automatically.
Now python domain supports the "~" prefix at the beginning of the
typehints of the function signatures:
.. py:function:: func(x: ~typing.Dict)
It's rescognized as the same as python reference roles do
(ex. :py:class:`~typing.Dict`).
Since v0.2, python domain gives a special treatment for the exceptions
module to suppress its name on documenting exception classes. It had
been worthy on python2 era. But the module has been removed since
python3. Therefore, the special treatment becomes harmful for user
libraries. This removes it to render module names correctly.
Note: Now we've only supported python3. So this is not incompatible.
So far, DocFieldTransformer has split the field name for `:type:`
and `:param:` at the first whitespace. Therefore, it does not allow
to use a type containing whitespace (ex. `Dict[str, str]`).
This changes the splitting logic to divide the field name at the last
whitespace (a.k.a `rstrip()`). It allows to use whitespaces on types.
A duplicated warning is emitted when both canonical and its alias
objects are defined on the same document. But it should not be emitted
because they're the same object, not conflicted.
On parsing the types, the leading dot of the ellipsis (...) is considered
as a reference name. And its first dot is considered as a notation for
relative type reference (ex. ".ClassName"). As a result, it was converted
double dots unexpectedly.
This changes the parsing rule to treat the ellipsis as a symbol, not a
name.
Add a new config variable: python_use_unqualified_type_names. If enabled,
it goes to suppress the module name of the python reference if it can be
resolved.
Since its beginning, `:var:` field has created a cross-reference to the
attribute having the same name. It is meaningful only if the attribute
is documented by `py:attribute` directive. It means the `:var:` field
and `:attr:` role are almost the same and conflicted. Additionally,
the cross-reference points incorrect variable if the target is not
documented.
Thus, the cross-reference feature of `:var:` field is disabled.
