Skip to content

Crossreferences to standard library in mypy docs, part 2 #7660

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 3 commits into from
Oct 9, 2019
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
4 changes: 2 additions & 2 deletions docs/source/builtin_types.rst
Original file line number Diff line number Diff line change
Expand Up @@ -23,7 +23,7 @@ Type Description
====================== ===============================

The type ``Any`` and type constructors such as ``List``, ``Dict``,
``Iterable`` and ``Sequence`` are defined in the ``typing`` module.
``Iterable`` and ``Sequence`` are defined in the :py:mod:`typing` module.

The type ``Dict`` is a *generic* class, signified by type arguments within
``[...]``. For example, ``Dict[int, str]`` is a dictionary from integers to
Expand All @@ -35,6 +35,6 @@ strings and ``Dict[Any, Any]`` is a dictionary of dynamically typed
correspond to Python protocols. For example, a ``str`` object or a
``List[str]`` object is valid
when ``Iterable[str]`` or ``Sequence[str]`` is expected. Note that even though
they are similar to abstract base classes defined in ``collections.abc``
they are similar to abstract base classes defined in :py:mod:`collections.abc`
(formerly ``collections``), they are not identical, since the built-in
collection type objects do not support indexing.
34 changes: 17 additions & 17 deletions docs/source/common_issues.rst
Original file line number Diff line number Diff line change
Expand Up @@ -69,7 +69,7 @@ flagged as an error.
:ref:`reveal_type() <reveal-type>` might come in handy.

Note that sometimes library stubs have imprecise type information,
e.g. the ``pow()`` builtin returns ``Any`` (see `typeshed issue 285
e.g. the :py:func:`pow` builtin returns ``Any`` (see `typeshed issue 285
<https://github.com/python/typeshed/issues/285>`_ for the reason).

- **Some imports may be silently ignored**. Another source of
Expand Down Expand Up @@ -143,7 +143,7 @@ Another option is to explicitly annotate values with type ``Any`` --
mypy will let you perform arbitrary operations on ``Any``
values. Sometimes there is no more precise type you can use for a
particular value, especially if you use dynamic Python features
such as ``__getattr__``:
such as :py:meth:`__getattr__ <object.__getattr__>`:

.. code-block:: python

Expand Down Expand Up @@ -326,7 +326,7 @@ above example:
Complex type tests
------------------

Mypy can usually infer the types correctly when using ``isinstance()``
Mypy can usually infer the types correctly when using :py:func:`isinstance <isinstance>`
type tests, but for other kinds of checks you may need to add an
explicit type cast:

Expand All @@ -342,17 +342,17 @@ explicit type cast:

.. note::

Note that the ``object`` type used in the above example is similar
Note that the :py:class:`object` type used in the above example is similar
to ``Object`` in Java: it only supports operations defined for *all*
objects, such as equality and ``isinstance()``. The type ``Any``,
objects, such as equality and :py:func:`isinstance`. The type ``Any``,
in contrast, supports all operations, even if they may fail at
runtime. The cast above would have been unnecessary if the type of
``o`` was ``Any``.

Mypy can't infer the type of ``o`` after the ``type()`` check
because it only knows about ``isinstance()`` (and the latter is better
Mypy can't infer the type of ``o`` after the :py:class:`type() <type>` check
because it only knows about :py:func:`isinstance` (and the latter is better
style anyway). We can write the above code without a cast by using
``isinstance()``:
:py:func:`isinstance`:

.. code-block:: python

Expand All @@ -379,8 +379,8 @@ the targeted Python version or platform. This allows you to more effectively
typecheck code that supports multiple versions of Python or multiple operating
systems.

More specifically, mypy will understand the use of ``sys.version_info`` and
``sys.platform`` checks within ``if/elif/else`` statements. For example:
More specifically, mypy will understand the use of :py:data:`sys.version_info` and
:py:data:`sys.platform` checks within ``if/elif/else`` statements. For example:

.. code-block:: python

Expand Down Expand Up @@ -417,14 +417,14 @@ Example:
# The rest of this file doesn't apply to Windows.

Some other expressions exhibit similar behavior; in particular,
``typing.TYPE_CHECKING``, variables named ``MYPY``, and any variable
:py:data:`~typing.TYPE_CHECKING`, variables named ``MYPY``, and any variable
whose name is passed to ``--always-true`` or ``--always-false``.
(However, ``True`` and ``False`` are not treated specially!)

.. note::

Mypy currently does not support more complex checks, and does not assign
any special meaning when assigning a ``sys.version_info`` or ``sys.platform``
any special meaning when assigning a :py:data:`sys.version_info` or :py:data:`sys.platform`
check to a variable. This may change in future versions of mypy.

By default, mypy will use your current version of Python and your current
Expand Down Expand Up @@ -514,10 +514,10 @@ File ``bar.py``:

.. note::

The ``TYPE_CHECKING`` constant defined by the ``typing`` module
The :py:data:`~typing.TYPE_CHECKING` constant defined by the :py:mod:`typing` module
is ``False`` at runtime but ``True`` while type checking.

Python 3.5.1 doesn't have ``typing.TYPE_CHECKING``. An alternative is
Python 3.5.1 doesn't have :py:data:`~typing.TYPE_CHECKING`. An alternative is
to define a constant named ``MYPY`` that has the value ``False``
at runtime. Mypy considers it to be ``True`` when type checking.
Here's the above example modified to use ``MYPY``:
Expand All @@ -538,7 +538,7 @@ Using classes that are generic in stubs but not at runtime
----------------------------------------------------------

Some classes are declared as generic in stubs, but not at runtime. Examples
in the standard library include ``os.PathLike`` and ``queue.Queue``.
in the standard library include :py:class:`os.PathLike` and :py:class:`queue.Queue`.
Subscripting such a class will result in a runtime error:

.. code-block:: python
Expand All @@ -551,7 +551,7 @@ Subscripting such a class will result in a runtime error:
results: Queue[int] = Queue() # TypeError: 'type' object is not subscriptable

To avoid these errors while still having precise types you can either use
string literal types or ``typing.TYPE_CHECKING``:
string literal types or :py:data:`~typing.TYPE_CHECKING`:

.. code-block:: python

Expand Down Expand Up @@ -615,7 +615,7 @@ Consider this example:
c.x << 5 # Since this will fail!

To work around this problem consider whether "mutating" is actually part
of a protocol. If not, then one can use a ``@property`` in
of a protocol. If not, then one can use a :py:class:`@property <property>` in
the protocol definition:

.. code-block:: python
Expand Down
13 changes: 7 additions & 6 deletions docs/source/config_file.rst
Original file line number Diff line number Diff line change
Expand Up @@ -254,8 +254,8 @@ For more information, see the :ref:`None and optional handling <none-and-optiona
section of the command line docs.

``no_implicit_optional`` (bool, default False)
Changes the treatment of arguments with a default value of None by not implicitly
making their type Optional.
Changes the treatment of arguments with a default value of ``None`` by not implicitly
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I suppose the verbatim formatting was forgotten here, so added the Optional ref as well.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

+1

making their type :py:data:`~typing.Optional`.

``strict_optional`` (bool, default True)
Enables or disables strict Optional checks. If False, mypy treats ``None``
Expand Down Expand Up @@ -377,8 +377,9 @@ a list of import discovery options that may be used
User home directory and environment variables will be expanded.

``files`` (string)

A comma-separated list of paths which should be checked by mypy if none are given on the command
line. Supports recursive file globbing using :doc:`library/glob`, where ``*`` (e.g. ``*.py``) matches
line. Supports recursive file globbing using :py:mod:`glob`, where ``*`` (e.g. ``*.py``) matches
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please advise here. Both links lead to the same target: the glob module docs, but are rendered differently:

image

vs

image

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I like the second better. So +1 to the change. (Do we use this :doc: style elsewhere, and does it get rendered so longwindedly there too? I think it's not needed.)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There are a few :doc: roles that refer to standard library modules:

For more information see :doc:`official docs <python:library/dataclasses>`

Mypy supports Python :doc:`abstract base classes <library/abc>` (ABCs). Abstract classes

:doc:`ini file <python:library/configparser>` format. It should contain

abstract method or attribute. (See also :doc:`Python
abc module documentation <python:library/abc>`)

Do you suggest to replace them with the appropriate :mod: role?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It doesn't seem necessary, since those other places all specify link text.

We cannot hope to strive for 100% consistency everywhere.

files in the current directory and ``**/`` (e.g. ``**/*.py``) matches files in any directories below
the current one. User home directory and environment variables will be expanded.

Expand All @@ -399,7 +400,7 @@ section of the command line docs.
Specifies the OS platform for the target program, for example
``darwin`` or ``win32`` (meaning OS X or Windows, respectively).
The default is the current platform as revealed by Python's
``sys.platform`` variable.
:py:data:`sys.platform` variable.


Incremental mode
Expand All @@ -418,7 +419,7 @@ section of the command line docs.
variable.

Note that the cache is only read when incremental mode is enabled
but is always written to, unless the value is set to ``/dev/nul``
but is always written to, unless the value is set to ``/dev/null``
(UNIX) or ``nul`` (Windows).

``skip_version_check`` (bool, default False)
Expand Down Expand Up @@ -462,7 +463,7 @@ section of the command line docs.
Shows traceback on fatal error.

``custom_typing_module`` (string)
Specifies a custom module to use as a substitute for the ``typing`` module.
Specifies a custom module to use as a substitute for the :py:mod:`typing` module.

``custom_typeshed_dir`` (string)
Specifies an alternative directory to look for stubs instead of the
Expand Down
12 changes: 6 additions & 6 deletions docs/source/dynamic_typing.rst
Original file line number Diff line number Diff line change
Expand Up @@ -54,10 +54,10 @@ less effective, unless you are careful.
Any vs. object
--------------

The type ``object`` is another type that can have an instance of arbitrary
type as a value. Unlike ``Any``, ``object`` is an ordinary static type (it
The type :py:class:`object` is another type that can have an instance of arbitrary
type as a value. Unlike ``Any``, :py:class:`object` is an ordinary static type (it
is similar to ``Object`` in Java), and only operations valid for *all*
types are accepted for ``object`` values. These are all valid:
types are accepted for :py:class:`object` values. These are all valid:

.. code-block:: python

Expand All @@ -80,7 +80,7 @@ operations:
n = 1 # type: int
n = o # Error!

You can use ``cast()`` (see chapter :ref:`casts`) or ``isinstance`` to
go from a general type such as ``object`` to a more specific
type (subtype) such as ``int``. ``cast()`` is not needed with
You can use :py:func:`~typing.cast` (see chapter :ref:`casts`) or :py:func:`isinstance` to
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I have altered the rendering by including the parentheses to isinstance. Before:

image

After:

image

Both are functions - shouldn't both have parentheses in this case?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

+1. The only time it's better not to add () to a function is when we're talking about the function object (e.g. in the context of creating an alias or accessing attributes).

go from a general type such as :py:class:`object` to a more specific
type (subtype) such as ``int``. :py:func:`~typing.cast` is not needed with
dynamically typed values (values with type ``Any``).