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
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
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
