Mailman 3 January 2021 - Typing-sig

PEP 646 and PEP 612 concatenation
by Shantanu Jain Jan. 20, 2021

Jan. 20, 2021

Hello all, There's some overlap between PEP 612 and PEP 646 and I thought it would be good to start a discussion. Sorry if this has already been covered, just trying to catch up! :-) The current draft of PEP 646 includes this example: ``` Ts = TypeVarTuple('Ts') def f(func: Callable[[int, *Ts], Any]) -> Tuple[*Ts]: ... def foo(int, str, float): ... def bar(str, int, float): ... f(foo) # Valid; inferred type is Tuple[str, float] f(bar) # Not valid ``` This is similar to the Concatenate operator PEP 612 introduces. Compare: ``` P = ParamSpec('P') def f1(func: Callable[Concatenate[int, P], Any]) -> Callable[P, Any]: ... Ts = TypeVarTuple('Ts') def f2(func: Callable[[int, *Ts], Any]) -> Callable[[*Ts], Any]: ... ``` Question 1: Do f1 and f2 differ? I'm assuming f2 won't preserve keyword arguments like ParamSpec does and that a function that takes keyword-only arguments would be invalid if matched against a TypeVarTuple. But some language in the PEP mentioning that would be good. Question 2: Should ParamSpec support splatting? Should Concatenate exist at all? That is, in addition to (or instead of) `Callable[Concatenate[int, P], Any]` we spell it `Callable[[int, *P], Any]`. There shouldn't be any parsing / runtime concerns for ParamSpec splatting, since it would just be normal sequence unpacking. If Concatenate is destined to be vestigial, it's not too late to get rid of it! :-) If Concatenate should exist, should `Concatenate[x, Ts]` generally be a synonym for `[x, *Ts]`? Note that Concatenate can't serve as a replacement for PEP 646's proposed Unpack, since you can't spell `def f(*args: Unpack[Ts])` and stuff like `[int, *Ts, float]` becomes awkward. (But as far as I can tell, Unpack / splatting could do everything Concatenate would). Thanks, Shantanu

3 2

User-defined type guards
by Eric Traut Jan. 17, 2021

Jan. 17, 2021

I occasionally receive questions from pyright users about extending type narrowing to handle cases that are not possible with today’s Python type system. Typescript provides a useful facility called [user-defined type guards]( https://www.typescriptlang.org/docs/handbook/advanced-types.html#user-defin…) that allows users to extend the notion of type narrowing. It would be straightforward to add this idea to Python. Do others think this would be useful, and is there any interest in standardizing this? Here’s a concrete proposal. We could add a new generic type called `TypeGuard` in the `typing` module. It would be a subclass of bool, defined simply as: ```python class TypeGuard(bool, Generic[_T]): pass ``` If any function or method accepts one parameter and returns a `TypeGuard` type, a type checker would assume that the argument passed to this function can be narrowed to the type specified in the `TypeGuard` type argument. Here are a few examples: ```python from typing import Any, Generic, List, Tuple, TypeGuard, TypeVar _T = TypeVar("_T") def is_two_element_tuple(val: Tuple[_T, ...]) -> TypeGuard[Tuple[_T, _T]]: return TypeGuard(len(val) == 2) def foo(names: Tuple[str, ...]): if is_two_element_tuple(names): reveal_type(names) # Tuple[str, str] def is_string_list(val: List[object]) -> TypeGuard[List[str]]: return TypeGuard(all(isinstance(x, str) for x in val)) def bar(stuff: List[Any]): if is_string_list(stuff): reveal_type(stuff) # List[str] ``` Thoughts? Suggestions? -Eric --- Eric Traut Contributor to Pyright and Pylance Microsoft Corp.

12 59

Switch to modular typeshed finally happening (and soon)
by Jukka Lehtosalo Jan. 13, 2021

Jan. 13, 2021

I and Ivan Levkivskyi are planning to start implementing a switch to a modular typeshed. This will involve a new directory structure for typeshed. All tools that use typeshed will likely require some changes. Here's the announcement: https://github.com/python/typeshed/issues/2491#issuecomment-758751253 We discussed the plan last spring at typeshed, but the implementation got delayed until now. Let's continue the discussion in the above GitHub issue. It also contains the full proposal + incremental updates in additional comments. Jukka

1 0

Next tensor typing meeting: Monday 11th
by Matthew Rahtz Jan. 12, 2021

Jan. 12, 2021

Hey all, Happy New Year! Hope everyone had a good rest over the holidays. Our next tensor typing meeting will be on *Monday the 11th of January *at *6:00 PM London time/10:00 AM San Francisco time*. Our tentative agenda is: - Status updates - TensorAnnotations (https://github.com/deepmind/tensor_annotations): I'll give a quick introduction about how it works and how to use it, followed by discussion. (Have you used it? What's your experience been like? Any feature requests?) If anyone else would like to talk about something, let me know. As always, we'll meet at http://meet.google.com/fft-dzjq-ksu. (Notes from previous meetings are at https://docs.google.com/document/d/1oaG0V2ZE5BRDjd9N-Tr1N0IKGwZQcraIlZ0N8ay….) See you then! Best, Matthew

3 6