From e4333f557353ce7c225426f13f8d6b60d4d8499c Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Oleg=20H=C3=B6fling?= Date: Tue, 8 Oct 2019 23:59:46 +0200 Subject: [PATCH 1/3] revisited builtin_types.rst, common_issues.rst, config_file.rst MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Signed-off-by: Oleg Höfling --- docs/source/builtin_types.rst | 4 ++-- docs/source/common_issues.rst | 34 +++++++++++++++++----------------- docs/source/config_file.rst | 11 ++++++----- 3 files changed, 25 insertions(+), 24 deletions(-) diff --git a/docs/source/builtin_types.rst b/docs/source/builtin_types.rst index aabab9b22da8..b7ee556f15c1 100644 --- a/docs/source/builtin_types.rst +++ b/docs/source/builtin_types.rst @@ -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 @@ -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. diff --git a/docs/source/common_issues.rst b/docs/source/common_issues.rst index 45f60b042871..22c2a2a45820 100644 --- a/docs/source/common_issues.rst +++ b/docs/source/common_issues.rst @@ -69,7 +69,7 @@ flagged as an error. :ref:`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 `_ for the reason). - **Some imports may be silently ignored**. Another source of @@ -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__ `: .. code-block:: python @@ -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 ` type tests, but for other kinds of checks you may need to add an explicit type cast: @@ -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() ` 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 @@ -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 @@ -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 @@ -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``: @@ -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 @@ -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 @@ -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 ` in the protocol definition: .. code-block:: python diff --git a/docs/source/config_file.rst b/docs/source/config_file.rst index 521a9caffdd2..7a753739778b 100644 --- a/docs/source/config_file.rst +++ b/docs/source/config_file.rst @@ -254,8 +254,8 @@ For more information, see the :ref:`None and optional handling Date: Wed, 9 Oct 2019 00:18:32 +0200 Subject: [PATCH 2/3] fixed null device name MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Signed-off-by: Oleg Höfling --- docs/source/config_file.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/source/config_file.rst b/docs/source/config_file.rst index 7a753739778b..2307220a642d 100644 --- a/docs/source/config_file.rst +++ b/docs/source/config_file.rst @@ -419,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) From 943f159c65d3c8e7501c3f2927f1a8e7ca701b2e Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Oleg=20H=C3=B6fling?= Date: Wed, 9 Oct 2019 00:28:32 +0200 Subject: [PATCH 3/3] revisited dynamic_typing.rst MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Signed-off-by: Oleg Höfling --- docs/source/dynamic_typing.rst | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/docs/source/dynamic_typing.rst b/docs/source/dynamic_typing.rst index ba01b59948f3..cea5248a3712 100644 --- a/docs/source/dynamic_typing.rst +++ b/docs/source/dynamic_typing.rst @@ -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 @@ -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 +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``). pFad - Phonifier reborn

Pfad - The Proxy pFad of © 2024 Garber Painting. All rights reserved.

Note: This service is not intended for secure transactions such as banking, social media, email, or purchasing. Use at your own risk. We assume no liability whatsoever for broken pages.


Alternative Proxies:

Alternative Proxy

pFad Proxy

pFad v3 Proxy

pFad v4 Proxy