Mailman 3 February 2023 - Typing-sig

Opened and changed typing issues week 2023-W05
by Typing Bot 06 Feb '23

06 Feb '23

No issues or pull requests with the label 'topic: feature' were opened or updated last week in the typing repository on GitHub. All issues and pull requests with the label 'topic: feature' can be viewed under the following URL: https://github.com/python/typing/issues?q=label%3A%22topic%3A+feature%22

1 0

"Patterned" variadic generics
by Thomas Kehrenberg 03 Feb '23

03 Feb '23

PEP 646 brought us variadic generics, which are great, but consider these functions: def product(it1: Iterable[T1], it2: Iterable[T2]) -> Iterable[Tuple[T1, T2]]: ... def zip(it1: Iterable[T1], it2: Iterable[T2]) -> Iterable[Tuple[T1, T2]]: ... def map(f: Callable[[T1, T2], S], it1: Iterable[T1], it2: Iterable[T2]) -> Iterable[S]: ... def make_boxed(x1: T1, x2: T2) -> Tuple[Boxed[T1], Boxed[T2]]: ... If I wanted to generalize them to arbitrary arguments, my naive solution would be something like this: def product(*it: *Iterable[Ts]) -> Iterable[Tuple[*Ts]]: ... def zip(*it: *Iterable[Ts]) -> Iterable[Tuple[*Ts]]: ... def map(f: Callable[[*Ts], S], *it: *Iterable[Ts]) -> Iterable[S]: ... def make_boxed(*x: *Ts) -> Tuple[*Boxed[Ts]]: ... But this obviously doesn't work. And it's also hard to see how it could be made to work because `Iterable` can't be unpacked. Has anyone thought about this? It seems like it would be a very useful feature for typing the standard library. (The title calls this "patterned" because that's what was used in this Swift design doc: https://github.com/hborla/swift-evolution/blob/variadic-generics-vision/vis… ) Regards, Thomas

3 2

PEP 698 typing.override
by Steven Troxler 02 Feb '23

02 Feb '23

A few weeks back we merged PEP 698 for `typing.override` as a draft PEP, with no significant changes since the typing-sig discussion in [1] One of the things we decided for the initial proposal was to avoid any runtime behavior; we considered setting `__override__` but decided not to because (a) it is hard to get the ordering of decorators right for runtime behavior, it depends on which decorators are descriptor- versus wrapper-function-based (b) some objects have fixed slots and therefore cannot have `__override__` set at all, there's no way to produce runtime behavior in these cases I think we should reconsider for two reasons: (a) The author of the overrides library got back to us and specifically requested this [2], because he believes there's potential for libraries to make runtime use of @override, for example automatically applying docstrings from parent classes to child classes which could be useful for notebook users (b) We do indeed set a `__final__` attribute in the @final decorator [3], and after some more thought I think consistency is important My current opinion is that we should make a best-effort attempt to set the attribute (as we do in `(a)typing.final`) and document edge cases that can impact runtime behavior, while ignoring those edge cases in static checkers. Are there any objections before I start working on these changes? ------------------- [1] Previous thread about typing.override proposal: https://mail.python.org/archives/list/typing-sig@python.org/message/7JDW2PK… [2] Discussion in peps repo regarding `__override__` https://github.com/python/peps/pull/2830 [3] @typing.final logic today: https://github.com/python/cpython/blob/main/Lib/typing.py#L2630-L2636

4 7