PEP 484: Fix citation references (#2638)
This commit is contained in:
parent
9ef0bfe362
commit
85c4c86532
77
pep-0484.txt
77
pep-0484.txt
|
@ -46,7 +46,7 @@ Essentially, such a type checker acts as a very powerful linter.
|
||||||
a similar checker at run time for Design By Contract enforcement or
|
a similar checker at run time for Design By Contract enforcement or
|
||||||
JIT optimization, those tools are not yet as mature.)
|
JIT optimization, those tools are not yet as mature.)
|
||||||
|
|
||||||
The proposal is strongly inspired by mypy [mypy]_. For example, the
|
The proposal is strongly inspired by `mypy <mypy_>`_. For example, the
|
||||||
type "sequence of integers" can be written as ``Sequence[int]``. The
|
type "sequence of integers" can be written as ``Sequence[int]``. The
|
||||||
square brackets mean that no new syntax needs to be added to the
|
square brackets mean that no new syntax needs to be added to the
|
||||||
language. The example here uses a custom type ``Sequence``, imported
|
language. The example here uses a custom type ``Sequence``, imported
|
||||||
|
@ -68,8 +68,8 @@ Rationale and Goals
|
||||||
|
|
||||||
:pep:`3107` added support for arbitrary annotations on parts of a
|
:pep:`3107` added support for arbitrary annotations on parts of a
|
||||||
function definition. Although no meaning was assigned to annotations
|
function definition. Although no meaning was assigned to annotations
|
||||||
then, there has always been an implicit goal to use them for type
|
then, there has always been an `implicit goal to use them for type
|
||||||
hinting [gvr-artima]_, which is listed as the first possible use case
|
hinting <gvr-artima_>`_, which is listed as the first possible use case
|
||||||
in said PEP.
|
in said PEP.
|
||||||
|
|
||||||
This PEP aims to provide a standard syntax for type annotations,
|
This PEP aims to provide a standard syntax for type annotations,
|
||||||
|
@ -760,8 +760,8 @@ to the list, which would violate the variable's type in the caller.
|
||||||
It turns out such an argument acts *contravariantly*, whereas the
|
It turns out such an argument acts *contravariantly*, whereas the
|
||||||
intuitive answer (which is correct in case the function doesn't mutate
|
intuitive answer (which is correct in case the function doesn't mutate
|
||||||
its argument!) requires the argument to act *covariantly*. A longer
|
its argument!) requires the argument to act *covariantly*. A longer
|
||||||
introduction to these concepts can be found on Wikipedia
|
introduction to these concepts can be found on `Wikipedia
|
||||||
[wiki-variance]_ and in :pep:`483`; here we just show how to control
|
<wiki-variance_>`_ and in :pep:`483`; here we just show how to control
|
||||||
a type checker's behavior.
|
a type checker's behavior.
|
||||||
|
|
||||||
By default generic types are considered *invariant* in all type variables,
|
By default generic types are considered *invariant* in all type variables,
|
||||||
|
@ -1660,7 +1660,7 @@ Additional notes on stub files:
|
||||||
exported. (This makes it easier to re-export all objects from a
|
exported. (This makes it easier to re-export all objects from a
|
||||||
given module that may vary by Python version.)
|
given module that may vary by Python version.)
|
||||||
|
|
||||||
* Just like in normal Python files [importdocs]_, submodules
|
* Just like in `normal Python files <importdocs_>`_, submodules
|
||||||
automatically become exported attributes of their parent module
|
automatically become exported attributes of their parent module
|
||||||
when imported. For example, if the ``spam`` package has the
|
when imported. For example, if the ``spam`` package has the
|
||||||
following directory structure::
|
following directory structure::
|
||||||
|
@ -1861,8 +1861,8 @@ enabled by including a file named ``py.typed`` in the package.)
|
||||||
The Typeshed Repo
|
The Typeshed Repo
|
||||||
-----------------
|
-----------------
|
||||||
|
|
||||||
There is a shared repository where useful stubs are being collected
|
There is a `shared repository <typeshed_>`_ where useful stubs are being
|
||||||
[typeshed]_. Policies regarding the stubs collected here will be
|
collected. Policies regarding the stubs collected here will be
|
||||||
decided separately and reported in the repo's documentation.
|
decided separately and reported in the repo's documentation.
|
||||||
Note that stubs for a given package will not be included here
|
Note that stubs for a given package will not be included here
|
||||||
if the package owners have specifically requested that they be omitted.
|
if the package owners have specifically requested that they be omitted.
|
||||||
|
@ -2365,8 +2365,9 @@ evaluation. There are several things wrong with this idea, however.
|
||||||
is unheard of in English, and in other languages (e.g. C++) it is
|
is unheard of in English, and in other languages (e.g. C++) it is
|
||||||
used as a scoping operator, which is a very different beast. In
|
used as a scoping operator, which is a very different beast. In
|
||||||
contrast, the single colon for type hints reads naturally -- and no
|
contrast, the single colon for type hints reads naturally -- and no
|
||||||
wonder, since it was carefully designed for this purpose (the idea
|
wonder, since it was carefully designed for this purpose
|
||||||
long predates :pep:`3107` [gvr-artima]_). It is also used in the same
|
(`the idea <gvr-artima_>`_
|
||||||
|
long predates :pep:`3107`). It is also used in the same
|
||||||
fashion in other languages from Pascal to Swift.
|
fashion in other languages from Pascal to Swift.
|
||||||
|
|
||||||
* What would you do for return type annotations?
|
* What would you do for return type annotations?
|
||||||
|
@ -2397,8 +2398,8 @@ evaluation. There are several things wrong with this idea, however.
|
||||||
Other forms of new syntax
|
Other forms of new syntax
|
||||||
-------------------------
|
-------------------------
|
||||||
|
|
||||||
A few other forms of alternative syntax have been proposed, e.g. the
|
A few other forms of alternative syntax have been proposed, e.g. `the
|
||||||
introduction of a ``where`` keyword [roberge]_, and Cobra-inspired
|
introduction <roberge_>`_ of a ``where`` keyword, and Cobra-inspired
|
||||||
``requires`` clauses. But these all share a problem with the double
|
``requires`` clauses. But these all share a problem with the double
|
||||||
colon: they won't work for earlier versions of Python 3. The same
|
colon: they won't work for earlier versions of Python 3. The same
|
||||||
would apply to a new ``__future__`` import.
|
would apply to a new ``__future__`` import.
|
||||||
|
@ -2433,12 +2434,12 @@ problem would that solve? It would just be procrastination.
|
||||||
PEP Development Process
|
PEP Development Process
|
||||||
=======================
|
=======================
|
||||||
|
|
||||||
A live draft for this PEP lives on GitHub [github]_. There is also an
|
A live draft for this PEP lives on `GitHub <github_>`_. There is also an
|
||||||
issue tracker [issues]_, where much of the technical discussion takes
|
`issue tracker <issues_>`_, where much of the technical discussion takes
|
||||||
place.
|
place.
|
||||||
|
|
||||||
The draft on GitHub is updated regularly in small increments. The
|
The draft on GitHub is updated regularly in small increments. The
|
||||||
official PEPS repo [peps_] is (usually) only updated when a new draft
|
`official PEPS repo <peps_>`_ is (usually) only updated when a new draft
|
||||||
is posted to python-dev.
|
is posted to python-dev.
|
||||||
|
|
||||||
|
|
||||||
|
@ -2457,40 +2458,31 @@ Anders Hejlsberg, Alok Menghrajani, Travis E. Oliphant, Joe Pamer,
|
||||||
Raoul-Gabriel Urma, and Julien Verlaguet.
|
Raoul-Gabriel Urma, and Julien Verlaguet.
|
||||||
|
|
||||||
|
|
||||||
References
|
.. _mypy:
|
||||||
==========
|
|
||||||
|
|
||||||
.. [mypy]
|
|
||||||
http://mypy-lang.org
|
http://mypy-lang.org
|
||||||
|
|
||||||
.. [gvr-artima]
|
.. _gvr-artima:
|
||||||
http://www.artima.com/weblogs/viewpost.jsp?thread=85551
|
https://www.artima.com/weblogs/viewpost.jsp?thread=85551
|
||||||
|
|
||||||
.. [wiki-variance]
|
.. _wiki-variance:
|
||||||
http://en.wikipedia.org/wiki/Covariance_and_contravariance_%28computer_science%29
|
https://en.wikipedia.org/wiki/Covariance_and_contravariance_%28computer_science%29
|
||||||
|
|
||||||
.. [typeshed]
|
.. _typeshed:
|
||||||
https://github.com/python/typeshed/
|
https://github.com/python/typeshed
|
||||||
|
|
||||||
.. [pyflakes]
|
.. _roberge:
|
||||||
https://github.com/pyflakes/pyflakes/
|
https://aroberge.blogspot.com/2015/01/type-hinting-in-python-focus-on.html
|
||||||
|
|
||||||
.. [pylint]
|
.. _github:
|
||||||
http://www.pylint.org
|
|
||||||
|
|
||||||
.. [roberge]
|
|
||||||
http://aroberge.blogspot.com/2015/01/type-hinting-in-python-focus-on.html
|
|
||||||
|
|
||||||
.. [github]
|
|
||||||
https://github.com/python/typing
|
https://github.com/python/typing
|
||||||
|
|
||||||
.. [issues]
|
.. _issues:
|
||||||
https://github.com/python/typing/issues
|
https://github.com/python/typing/issues
|
||||||
|
|
||||||
.. [peps]
|
.. _peps:
|
||||||
https://hg.python.org/peps/file/tip/pep-0484.txt
|
https://hg.python.org/peps/file/tip/pep-0484.txt
|
||||||
|
|
||||||
.. [importdocs]
|
.. _importdocs:
|
||||||
https://docs.python.org/3/reference/import.html#submodules
|
https://docs.python.org/3/reference/import.html#submodules
|
||||||
|
|
||||||
|
|
||||||
|
@ -2498,14 +2490,3 @@ Copyright
|
||||||
=========
|
=========
|
||||||
|
|
||||||
This document has been placed in the public domain.
|
This document has been placed in the public domain.
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
..
|
|
||||||
Local Variables:
|
|
||||||
mode: indented-text
|
|
||||||
indent-tabs-mode: nil
|
|
||||||
sentence-end-double-space: t
|
|
||||||
fill-column: 70
|
|
||||||
coding: utf-8
|
|
||||||
End:
|
|
||||||
|
|
Loading…
Reference in New Issue