Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

PEP 742: Allow inferring the intersection type; carry over TypeGuard spec change #3696

Merged
merged 1 commit into from Feb 29, 2024
Merged
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Jump to
Jump to file
Failed to load files.
Diff view
Diff view
11 changes: 6 additions & 5 deletions peps/pep-0742.rst
Expand Up @@ -190,6 +190,8 @@ argument's previously-known type::

def f(x: Awaitable[int] | int) -> None:
if isawaitable(x):
# Type checkers may also infer the more precise type
# "Awaitable[int] | (int & Awaitable[Any])"
assert_type(x, Awaitable[int])
else:
assert_type(x, int)
Expand All @@ -204,11 +206,10 @@ It is an error to narrow to a type that is not consistent with the input type::
Subtyping
---------

``TypeIs`` is not a subtype of ``bool``.
The type ``Callable[..., TypeIs[int]]`` is not assignable to
``Callable[..., bool]`` or ``Callable[..., TypeGuard[int]]``, and vice versa.
This restriction is carried over from :pep:`647`. It may be possible to relax
it in the future, but that is outside the scope of this PEP.
``TypeIs`` is also valid as the return type of a callable, for example
in callback protocols and in the ``Callable`` special form. In these
contexts, it is treated as a subtype of bool. For example, ``Callable[..., TypeIs[int]]``
is assignable to ``Callable[..., bool]``.

Unlike ``TypeGuard``, ``TypeIs`` is invariant in its argument type:
``TypeIs[B]`` is not a subtype of ``TypeIs[A]``,
Expand Down