I'd like to make the fact that this does nothing at runtime
really obvious, since I suspect this is unintuitive for users who are
unfamiliar with static type checking.
I thought of this because of
https://discuss.python.org/t/add-arg-check-type-to-types/26384
wherein I'm skeptical that the user really did want `assert_type`.
Previously, this used to fail:
```py
from typing import *
T = TypeVar("T")
P = ParamSpec("P")
class X(Generic[P]):
f: Callable[P, int]
Y = X[[int, T]]
Z = Y[str]
```
Co-authored-by: Alex Waygood <Alex.Waygood@Gmail.com>
* Fix substitution of TypeVarTuple and ParamSpec together in user generics.
* Fix substitution of ParamSpec followed by TypeVarTuple in generic aliases.
* Check the number of arguments in substitution in user generics containing a
TypeVarTuple and one or more TypeVar.
Fix subscription of type aliases containing bare generic types or types
like TypeVar: for example tuple[A, T][int] and tuple[TypeVar, T][int],
where A is a generic type, and T is a type variable.
The existing test covering this case passed only incidentally. We
explicitly disallow doing this and add a proper error message.
Co-authored-by: Serhiy Storchaka <storchaka@gmail.com>
This mirrors logic in typing.get_args. The trickiness comes from how we
flatten args in collections.abc.Callable, see
https://bugs.python.org/issue42195
Copied from typing-extensions (python/typing#1054, python/typing#1120).
Documentation is intentionally omitted, so we can focus on getting the
runtime part in before the feature freeze.
Based on suggestions by Guido van Rossum, Spencer Brown, and Alex Waygood.
Co-authored-by: Alex Waygood <Alex.Waygood@Gmail.com>
Co-authored-by: Guido van Rossum <gvanrossum@gmail.com>
Co-authored-by: Ken Jin <kenjin4096@gmail.com>
I talked to @davidfstr and I offered to implement the runtime part of PEP 655
to make sure we can get it in before the feature freeze. We're going to defer
the documentation to a separate PR, because it can wait until after the feature
freeze.
The runtime implementation conveniently already exists in typing-extensions,
so I largely copied that.
Co-authored-by: David Foster <david@dafoster.net>
The goal here is to reduce potential confusion between
`assert_type(val, type)` and `assert isinstance(val, typ)`.
The former is meant to ask a type checker to confirm a fact, the latter
is meant to tell a type checker a fact. The behaviour of the latter more
closely resembles what I'd expect from the prior phrasing of
"assert [something] to the type checker".
Add methods __typing_subst__() in TypeVar and ParamSpec.
Simplify code by using more object-oriented approach, especially
the C code for types.GenericAlias and the Python code for
collections.abc.Callable.
GH-26091 added the _typevar_types and _paramspec_tvars instance
variables to _GenericAlias. However, they were not propagated
consistently. This commit addresses the most prominent deficiency
identified in bpo-46581 (namely their absence from
_GenericAlias.copy_with), but there could be others.
Co-authored-by: Ken Jin <28750310+Fidget-Spinner@users.noreply.github.com>
Co-authored-by: Serhiy Storchaka <storchaka@gmail.com>
Co-authored-by: Alex Waygood <alex.waygood@gmail.com>
Co-authored-by: Nikita Sobolev <mail@sobolevn.me>
Co-authored-by: Ken Jin <28750310+Fidget-Spinner@users.noreply.github.com>
This removes discrepancy between list["int"] and List["int"].
Co-authored-by: Jelle Zijlstra <jelle.zijlstra@gmail.com>
Co-authored-by: Alex Waygood <Alex.Waygood@Gmail.com>
There are several changes:
1. We now don't explicitly check for any base / sub types, because new name check covers it
2. I've also checked that `no_type_check` do not modify foreign functions. It was the same as with `type`s
3. I've also covered `except TypeError` in `no_type_check` with a simple test case, it was not covered at all
4. I also felt like adding `lambda` test is a good idea: because `lambda` is a bit of both in class bodies: a function and an assignment
<!-- issue-number: [bpo-46571](https://bugs.python.org/issue46571) -->
https://bugs.python.org/issue46571
<!-- /issue-number -->
The `module` parameter carries semantic information about the forward ref.
Forward refs are different if they refer to different module even if they
have the same name. This affects the `__eq__`, `__repr__` and `__hash__` methods.
Co-authored-by: Andreas Hangauer <andreas.hangauer@siemens.com>
Co-authored-by: Alex Waygood <Alex.Waygood@Gmail.com>
Co-authored-by: Ken Jin <28750310+Fidget-Spinner@users.noreply.github.com>
The module parameter carries semantic information about the forward ref.
Show to the user that forward refs with same argument but different
module are different.
Co-authored-by: Andreas Hangauer <andreas.hangauer@siemens.com>
Co-authored-by: blurb-it[bot] <43283697+blurb-it[bot]@users.noreply.github.com>
* Substitution with a list of types returns now a tuple of types.
* Substitution with Concatenate returns now a Concatenate with
concatenated lists of arguments.
* Substitution with Ellipsis is not supported.
Previously this didn't matter because there weren't any valid code paths
that could trigger a type check with a special form, but after the bug
fix for `Annotated` wrapping special forms it's now possible to annotate
something like `Annotated['ClassVar[int]', (3, 4)]`. This change would
also be needed for proposed future changes, such as allowing `ClassVar`
and `Final` to nest each other in dataclasses.
We treat Annotated type arg as class-level annotation. This exempts it from checks against Final and ClassVar in order to allow using them in any nesting order.
Automerge-Triggered-By: GH:gvanrossum
For example Callable[P, T][[int], str, float] will now raise an error.
Use also term "arguments" instead of "parameters" in error
message for too few/many arguments.