iSharkFly-Open
/
python-peps
mirror of https://github.com/python/peps.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

PEP 612: Renaming type_variable_operators to operators and adding an explanation (#1546) 

* explaining why we have to special case *args: P.args

* typing.type_variable_operators.Concatenate -> typing.Concatenate
This commit is contained in:
Mark Mendoza 2020-07-31 19:59:17 -07:00 committed by GitHub
parent f5d19f3628
commit d0e2f3bbaa
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
1 changed files with 8 additions and 3 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

11
pep-0612.rst
View File

@ -22,7 +22,7 @@ There currently are two ways to specify the type of a callable, the
544 <https://www.python.org/dev/peps/pep-0544/#callback-protocols>`_. Neither of 544 <https://www.python.org/dev/peps/pep-0544/#callback-protocols>`_. Neither of
these support forwarding the parameter types of one callable over to another these support forwarding the parameter types of one callable over to another
callable, making it difficult to annotate function decorators. This PEP proposes callable, making it difficult to annotate function decorators. This PEP proposes
``typing.ParamSpec`` and ``typing.type_variable_operators.Concatenate`` to ``typing.ParamSpec`` and ``typing.Concatenate`` to
support expressing these kinds of relationships. support expressing these kinds of relationships.
Motivation Motivation
@ -129,7 +129,7 @@ type this more complex decorator.
.. code-block:: .. code-block::
from typing.type_variable_operators import Concatenate from typing import Concatenate
def with_request(f: Callable[Concatenate[Request, P], R]) -> Callable[P, R]: def with_request(f: Callable[Concatenate[Request, P], R]) -> Callable[P, R]:
def inner(*args: P.args, **kwargs: P.kwargs) -> R: def inner(*args: P.args, **kwargs: P.kwargs) -> R:
@ -191,7 +191,7 @@ parameter specification variable (``Callable[Concatenate[int, P], int]``\ ).
where ``parameter_specification_variable`` is a ``typing.ParamSpec`` variable, where ``parameter_specification_variable`` is a ``typing.ParamSpec`` variable,
declared in the manner as defined above, and ``concatenate`` is declared in the manner as defined above, and ``concatenate`` is
``typing.type_variable_operators.Concatenate``. ``typing.Concatenate``.
As before, ``parameters_expression``\ s by themselves are not acceptable in As before, ``parameters_expression``\ s by themselves are not acceptable in
places where a type is expected places where a type is expected
@ -434,6 +434,11 @@ afforded to us by this set up:
* Inside the function, ``args`` has the type ``P.args``\ , not * Inside the function, ``args`` has the type ``P.args``\ , not
``Tuple[P.args, ...]`` as would be with a normal annotation ``Tuple[P.args, ...]`` as would be with a normal annotation
(and likewise with the ``**kwargs``\ ) (and likewise with the ``**kwargs``\ )
* This special case is necessary to encapsulate the heterogenous contents
of the ``args``/``kwargs`` of a given call, which cannot be expressed
by an indefinite tuple/dictionary type.
* A function of type ``Callable[P, R]`` can be called with ``(*args, **kwargs)`` * A function of type ``Callable[P, R]`` can be called with ``(*args, **kwargs)``
if and only if ``args`` has the type ``P.args`` and ``kwargs`` has the type if and only if ``args`` has the type ``P.args`` and ``kwargs`` has the type
``P.kwargs``\ , and that those types both originated from the same function ``P.kwargs``\ , and that those types both originated from the same function