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

PEP 696: consolidate discussion of constraint solving in "Function Defaults" section, add new "Subtyping" section (#3648) 

* PEP 696: consolidate discussion of constraint solving.

Consolidates discussion of usage of defaults in constraint solving in
the "Function Defaults" section, to make it clear that this is
experimental and unspecified.

* PEP 696: Explicitly call out that defaults do not affect subtyping.
This commit is contained in:
Rebecca Chen 2024-02-07 16:44:55 -08:00 committed by GitHub
parent 2b913684ca
commit 4f151e9777
No known key found for this signature in database
GPG Key ID: B5690EEEBB952194
1 changed files with 21 additions and 9 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

30
peps/pep-0696.rst
View File

@ -17,8 +17,7 @@ Abstract
This PEP introduces the concept of type defaults for type parameters,
including ``TypeVar``, ``ParamSpec``, and ``TypeVarTuple``,
which act as defaults for a type parameter when one is not specified or
the constraint solver isn't able to solve a type parameter to anything.
which act as defaults for type parameters for which no type is specified.
Default type argument support is available in some popular languages
such as C++, TypeScript, and Rust. A survey of type parameter syntax in
@ -182,8 +181,7 @@ or another in-scope ``TypeVarTuple`` (see `Scoping Rules`_).
Using Another Type Parameter as ``default``
''''''''''''''''''''''''''''''''''''''''''''
This allows for a value to be used again when the constraints solver
fails to solve a constraint for a type, or the type parameter to a
This allows for a value to be used again when the type parameter to a
generic is missing but another type parameter is specified.
To use another type parameter as a default the ``default`` and the
@ -373,11 +371,18 @@ subtype of one of the constraints.
Function Defaults
'''''''''''''''''
We leave the semantics of type parameter defaults in generic functions
unspecified, as ensuring the ``default`` is returned in every code path
where the type parameter can go unsolved may be too hard to implement.
Type checkers are free to either disallow this case or experiment with
implementing support.
In generic functions, type checkers may use a type parameter's default when the
type parameter cannot be solved to anything. We leave the semantics of this
usage unspecified, as ensuring the ``default`` is returned in every code path
where the type parameter can go unsolved may be too hard to implement. Type
checkers are free to either disallow this case or experiment with implementing
support.
::
T = TypeVar('T', default=int)
def func(x: int | set[T]) -> T: ...
reveal_type(func(0)) # a type checker may reveal T's default of int here
Defaults following ``TypeVarTuple``
'''''''''''''''''''''''''''''''''''
@ -413,6 +418,13 @@ for the ``ParamSpec`` and one for the ``TypeVarTuple``.
Foo[int, str] # Ts = (int, str), P = [float, bool]
Foo[int, str, [bytes]] # Ts = (int, str), P = [bytes]
Subtyping
'''''''''
Type parameter defaults do not affect the subtyping rules for generic classes.
In particular, defaults can be ignored when considering whether a class is
compatible with a generic protocol.
``TypeVarTuple``\ s as Defaults
'''''''''''''''''''''''''''''''