@@ -69,7 +69,7 @@ flagged as an error.
69
69
:ref: `reveal_type() <reveal-type >` might come in handy.
70
70
71
71
Note that sometimes library stubs have imprecise type information,
72
- e.g. the `` pow() ` ` builtin returns ``Any `` (see `typeshed issue 285
72
+ e.g. the :py:func: ` pow ` builtin returns ``Any `` (see `typeshed issue 285
73
73
<https://github.com/python/typeshed/issues/285> `_ for the reason).
74
74
75
75
- **Some imports may be silently ignored **. Another source of
@@ -143,7 +143,7 @@ Another option is to explicitly annotate values with type ``Any`` --
143
143
mypy will let you perform arbitrary operations on ``Any ``
144
144
values. Sometimes there is no more precise type you can use for a
145
145
particular value, especially if you use dynamic Python features
146
- such as `` __getattr__ ` `:
146
+ such as :py:meth: ` __getattr__ <object.__getattr__> `:
147
147
148
148
.. code-block :: python
149
149
@@ -326,7 +326,7 @@ above example:
326
326
Complex type tests
327
327
------------------
328
328
329
- Mypy can usually infer the types correctly when using `` isinstance() ` `
329
+ Mypy can usually infer the types correctly when using :py:func: ` isinstance <isinstance> `
330
330
type tests, but for other kinds of checks you may need to add an
331
331
explicit type cast:
332
332
@@ -342,17 +342,17 @@ explicit type cast:
342
342
343
343
.. note ::
344
344
345
- Note that the `` object ` ` type used in the above example is similar
345
+ Note that the :py:class: ` object ` type used in the above example is similar
346
346
to ``Object `` in Java: it only supports operations defined for *all *
347
- objects, such as equality and `` isinstance() ` `. The type ``Any ``,
347
+ objects, such as equality and :py:func: ` isinstance `. The type ``Any ``,
348
348
in contrast, supports all operations, even if they may fail at
349
349
runtime. The cast above would have been unnecessary if the type of
350
350
``o `` was ``Any ``.
351
351
352
- Mypy can't infer the type of ``o `` after the `` type() ` ` check
353
- because it only knows about `` isinstance() ` ` (and the latter is better
352
+ Mypy can't infer the type of ``o `` after the :py:class: ` type() <type> ` check
353
+ because it only knows about :py:func: ` isinstance ` (and the latter is better
354
354
style anyway). We can write the above code without a cast by using
355
- `` isinstance() ` `:
355
+ :py:func: ` isinstance `:
356
356
357
357
.. code-block :: python
358
358
@@ -379,8 +379,8 @@ the targeted Python version or platform. This allows you to more effectively
379
379
typecheck code that supports multiple versions of Python or multiple operating
380
380
systems.
381
381
382
- More specifically, mypy will understand the use of `` sys.version_info ` ` and
383
- `` sys.platform ` ` checks within ``if/elif/else `` statements. For example:
382
+ More specifically, mypy will understand the use of :py:data: ` sys.version_info ` and
383
+ :py:data: ` sys.platform ` checks within ``if/elif/else `` statements. For example:
384
384
385
385
.. code-block :: python
386
386
@@ -417,14 +417,14 @@ Example:
417
417
# The rest of this file doesn't apply to Windows.
418
418
419
419
Some other expressions exhibit similar behavior; in particular,
420
- `` typing.TYPE_CHECKING ` `, variables named ``MYPY ``, and any variable
420
+ :py:data: ` ~ typing.TYPE_CHECKING `, variables named ``MYPY ``, and any variable
421
421
whose name is passed to ``--always-true `` or ``--always-false ``.
422
422
(However, ``True `` and ``False `` are not treated specially!)
423
423
424
424
.. note ::
425
425
426
426
Mypy currently does not support more complex checks, and does not assign
427
- any special meaning when assigning a `` sys.version_info `` or `` sys.platform ` `
427
+ any special meaning when assigning a :py:data: ` sys.version_info ` or :py:data: ` sys.platform `
428
428
check to a variable. This may change in future versions of mypy.
429
429
430
430
By default, mypy will use your current version of Python and your current
@@ -514,10 +514,10 @@ File ``bar.py``:
514
514
515
515
.. note ::
516
516
517
- The `` TYPE_CHECKING `` constant defined by the `` typing ` ` module
517
+ The :py:data: ` ~typing. TYPE_CHECKING ` constant defined by the :py:mod: ` typing ` module
518
518
is ``False `` at runtime but ``True `` while type checking.
519
519
520
- Python 3.5.1 doesn't have `` typing.TYPE_CHECKING ` `. An alternative is
520
+ Python 3.5.1 doesn't have :py:data: ` ~ typing.TYPE_CHECKING `. An alternative is
521
521
to define a constant named ``MYPY `` that has the value ``False ``
522
522
at runtime. Mypy considers it to be ``True `` when type checking.
523
523
Here's the above example modified to use ``MYPY ``:
@@ -538,7 +538,7 @@ Using classes that are generic in stubs but not at runtime
538
538
----------------------------------------------------------
539
539
540
540
Some classes are declared as generic in stubs, but not at runtime. Examples
541
- in the standard library include `` os.PathLike `` and `` queue.Queue ` `.
541
+ in the standard library include :py:class: ` os.PathLike ` and :py:class: ` queue.Queue `.
542
542
Subscripting such a class will result in a runtime error:
543
543
544
544
.. code-block :: python
@@ -551,7 +551,7 @@ Subscripting such a class will result in a runtime error:
551
551
results: Queue[int ] = Queue() # TypeError: 'type' object is not subscriptable
552
552
553
553
To avoid these errors while still having precise types you can either use
554
- string literal types or `` typing.TYPE_CHECKING ` `:
554
+ string literal types or :py:data: ` ~ typing.TYPE_CHECKING `:
555
555
556
556
.. code-block :: python
557
557
@@ -615,7 +615,7 @@ Consider this example:
615
615
c.x << 5 # Since this will fail!
616
616
617
617
To work around this problem consider whether "mutating" is actually part
618
- of a protocol. If not, then one can use a `` @property ` ` in
618
+ of a protocol. If not, then one can use a :py:class: ` @property <property> ` in
619
619
the protocol definition:
620
620
621
621
.. code-block :: python
0 commit comments