Something to consider is whether this new form should be limited to the functionality provided by `Callable` or whether it should be expanded to support the full range of supported callable signatures. This would include: 1. The use of *args and **kwargs parameters 2. Keyword (named) parameters 3. Position-only and keyword-only separators (`/` and `*`, respectively) The new proposed syntax could support all of these if desired. I suspect this is where Łukasz was going with his line of thinking. But his proposal (if I understand it correctly) blurs the lines between a function declaration and a callable type declaration. I'd encourage us to keep those distinct. We can (and should) adopt similar syntax for both cases though. Examples: ```python C1 = (x: float, /) -> float # Equivalent to Callable[[float], float] C2 = (x: float) -> float # Not expressible with Callable C3 = (*, x: float) -> float # Not expressible with Callable C4 = (v: int, /, x: float) -> float # Not expressible with Callable C5 = (x: int, *args: str, **kwargs: str) -> int # Not expressible with Callable C6 = (*args: Any, **kwargs: Any) -> None # Equivalent to Callable[..., None] ``` Note that `C6` above handles the `Callable[..., None]` case that Sebastian raised. Another potential consideration is support for PEP 612. Callable handles `ParamSpec` and `Concatenate` in a way that would be difficult to support using this alternate syntax. These are edge cases, so perhaps it's fine to say that you need to fall back on `Callable` if you want to use `ParamSpec` and `Concatenate`. -Eric --- Eric Traut Contributor to Pylance & Pyright Microsoft Corp.