mirror of
https://github.com/astral-sh/ruff.git
synced 2025-11-20 04:29:47 +00:00
cb2e277482
## Summary This PR adds support for understanding the legacy definition and PEP 695 definition for `ParamSpec`. This is still very initial and doesn't really implement any of the semantics. Part of https://github.com/astral-sh/ty/issues/157 ## Test Plan Add mdtest cases. ## Ecosystem analysis Most of the diagnostics in `starlette` are due to the fact that ty now understands `ParamSpec` is not a `Todo` type, so the assignability check fails. The code looks something like: ```py class _MiddlewareFactory(Protocol[P]): def __call__(self, app: ASGIApp, /, *args: P.args, **kwargs: P.kwargs) -> ASGIApp: ... # pragma: no cover class Middleware: def __init__( self, cls: _MiddlewareFactory[P], *args: P.args, **kwargs: P.kwargs, ) -> None: self.cls = cls self.args = args self.kwargs = kwargs # ty complains that `ServerErrorMiddleware` is not assignable to `_MiddlewareFactory[P]` Middleware(ServerErrorMiddleware, handler=error_handler, debug=debug) ``` There are multiple diagnostics where there's an attribute access on the `Wrapped` object of `functools` which Pyright also raises: ```py from functools import wraps def my_decorator(f): @wraps(f) def wrapper(*args, **kwds): return f(*args, **kwds) # Pyright: Cannot access attribute "__signature__" for class "_Wrapped[..., Unknown, ..., Unknown]" Attribute "__signature__" is unknown [reportAttributeAccessIssue] # ty: Object of type `_Wrapped[Unknown, Unknown, Unknown, Unknown]` has no attribute `__signature__` [unresolved-attribute] wrapper.__signature__ return wrapper ``` There are additional diagnostics that is due to the assignability checks failing because ty now infers the `ParamSpec` instead of using the `Todo` type which would always succeed. This results in a few `no-matching-overload` diagnostics because the assignability checks fail. There are a few diagnostics related to https://github.com/astral-sh/ty/issues/491 where there's a variable which is either a bound method or a variable that's annotated with `Callable` that doesn't contain the instance as the first parameter. Another set of (valid) diagnostics are where the code hasn't provided all the type variables. ty is now raising diagnostics for these because we include `ParamSpec` type variable in the signature. For example, `staticmethod[Any]` which contains two type variables.
3.2 KiB
3.2 KiB
ParamSpec
Definition
Valid
from typing import ParamSpec
P = ParamSpec("P")
reveal_type(type(P)) # revealed: <class 'ParamSpec'>
reveal_type(P) # revealed: typing.ParamSpec
reveal_type(P.__name__) # revealed: Literal["P"]
The paramspec name can also be provided as a keyword argument:
from typing import ParamSpec
P = ParamSpec(name="P")
reveal_type(P.__name__) # revealed: Literal["P"]
Must be directly assigned to a variable
from typing import ParamSpec
P = ParamSpec("P")
# error: [invalid-paramspec]
P1: ParamSpec = ParamSpec("P1")
# error: [invalid-paramspec]
tuple_with_typevar = ("foo", ParamSpec("W"))
reveal_type(tuple_with_typevar[1]) # revealed: ParamSpec
from typing_extensions import ParamSpec
T = ParamSpec("T")
# error: [invalid-paramspec]
P1: ParamSpec = ParamSpec("P1")
# error: [invalid-paramspec]
tuple_with_typevar = ("foo", ParamSpec("P2"))
reveal_type(tuple_with_typevar[1]) # revealed: ParamSpec
ParamSpec parameter must match variable name
from typing import ParamSpec
P1 = ParamSpec("P1")
# error: [invalid-paramspec]
P2 = ParamSpec("P3")
Accepts only a single name argument
The runtime should accept bounds and covariant and contravariant arguments in the declaration just as typing.TypeVar does, but for now we will defer the standardization of the semantics of those options to a later PEP.
from typing import ParamSpec
# error: [invalid-paramspec]
P1 = ParamSpec("P1", bound=int)
# error: [invalid-paramspec]
P2 = ParamSpec("P2", int, str)
# error: [invalid-paramspec]
P3 = ParamSpec("P3", covariant=True)
# error: [invalid-paramspec]
P4 = ParamSpec("P4", contravariant=True)
Defaults
[environment]
python-version = "3.13"
The default value for a ParamSpec can be either a list of types, ..., or another ParamSpec.
from typing import ParamSpec
P1 = ParamSpec("P1", default=[int, str])
P2 = ParamSpec("P2", default=...)
P3 = ParamSpec("P3", default=P2)
Other values are invalid.
# error: [invalid-paramspec]
P4 = ParamSpec("P4", default=int)
PEP 695
[environment]
python-version = "3.12"
Valid
def foo1[**P]() -> None:
reveal_type(P) # revealed: typing.ParamSpec
def foo2[**P = ...]() -> None:
reveal_type(P) # revealed: typing.ParamSpec
def foo3[**P = [int, str]]() -> None:
reveal_type(P) # revealed: typing.ParamSpec
def foo4[**P, **Q = P]():
reveal_type(P) # revealed: typing.ParamSpec
reveal_type(Q) # revealed: typing.ParamSpec
Invalid
ParamSpec, when defined using the new syntax, does not allow defining bounds or constraints.
This results in a lot of syntax errors mainly because the AST doesn't accept them in this position. The parser could do a better job in recovering from these errors.
# error: [invalid-syntax]
# error: [invalid-syntax]
# error: [invalid-syntax]
# error: [invalid-syntax]
# error: [invalid-syntax]
# error: [invalid-syntax]
def foo[**P: int]() -> None:
# error: [invalid-syntax]
# error: [invalid-syntax]
pass
Invalid default
# error: [invalid-paramspec]
def foo[**P = int]() -> None:
pass