Mailman 3 February 2023 - Typing-sig

Re: Typing Meetup
by S Pradeep Kumar Sept. 19, 2023

Sept. 19, 2023

Updating the Typing Meetup date to Wednesday as there were some conflicts. Let me know if there are any major time conflicts. Date: *Wednesday, November 03, 2021.*Time: 10 am San Francisco time (UTC-7) / 5 pm London time (UTC) Duration: 1 hour Potential discussion topics: + Typing **kwargs using a TypedDict (Franek Magiera?, Pradeep) [1] + Remaining questions about Callable syntax (Steven) + Non-required Protocol fields (Sebastian Rittau?) [2] + Type support for sealed classes (Adrian Freund?) [3] + Safe, typed JSON validation + Type system documentation (Shannon?) If you're working on these or any other topics and would like to start a discussion at the meetup, reach out to me. If you have interesting topics you'd like to see discussed, share them too. Once we have topics, we can always start a discussion even if there's no proposer yet. We will probably have time for 3-4 topics in this session. On Fri, Oct 15, 2021 at 12:55 PM S Pradeep Kumar <gohanpra(a)gmail.com> wrote: >>> >>>> Hello all, >>>> >>>> We plan to hold a virtual Typing Meetup to discuss key typing-related >>>> issues in real-time. The idea is that we can make progress on important or >>>> controversial discussions, get early feedback on in-progress PEPs, and >>>> gauge interest in new proposals. >>>> >>>> A virtual meetup will be more accessible to people in other timezones >>>> than Bay Area in-person meetups. It should also help consolidate >>>> discussions that are often spread out across mailing lists or Github repos. >>>> The tentative plan is to have a monthly meetup, but we can change that as >>>> needed. >>>> >>>> Date: Monday, November 01, 2021. >>>> Time: 10 am San Francisco time (UTC-7) / 5 pm London time (UTC) >>>> Duration: 1 hour >>>> >>>> Time and date are flexible. I'll share the zoom link and agenda the >>>> week before. I'll also record the meetup and share afterwards. >>>> >>>> If you're interested in presenting a new proposal or your work on some >>>> existing proposal, please respond here. We can shoot for 15 minutes per >>>> presentation. I know there are quite a few interesting threads on >>>> typing-sig that haven't seen much activity in a while :) >>>> -- >>>> S Pradeep Kumar >>>> _______________________________________________ >>>> Typing-sig mailing list -- typing-sig(a)python.org >>>> To unsubscribe send an email to typing-sig-leave(a)python.org >>>> https://mail.python.org/mailman3/lists/typing-sig.python.org/ >>>> Member address: guido(a)python.org >>> >>> Links: [1] Typing **kwargs using TypedDict: https://mail.python.org/archives/list/typing-sig@python.org/thread/IUCXT2IQ… [2] Non-required Protocol fields: https://mail.python.org/archives/list/typing-sig@python.org/thread/P6FCGRJU… [3] Sealed classes: https://mail.python.org/archives/list/typing-sig@python.org/thread/QSCT2N4R… -- S Pradeep Kumar

10 60

Type narrowing for TypeGuard in the negative case
by Eric Traut Aug. 4, 2023

Aug. 4, 2023

Since the introduction of PEP 647 (User-defined Type Guards), we've received a steady stream of input from users saying that they don't like the limitation that type narrowing is applied only in the positive case and is not applied in the negative case. In general, type narrowing is not safe to perform if a user-defined type guard returns False, so I've stood by the original decision not to provide type narrowing in the negative case, but there are cases where such narrowing is safe and desirable. Here's a recent thread where this was discussed in some detail: https://github.com/python/typing/issues/996#issuecomment-1002716830 In this discussion, Ilya Kamen proposed a solution. The proposal is to extend the existing `TypeGuard` to support an optional second type argument. If present, the second argument indicates the narrowed type in the negative type narrowing situation. Here's a simple (admittedly contrived) example: ```python def is_str(val: str | int) -> TypeGuard[str, int]: return isinstance(val, str) def func(val: str | int): if is_str(val): reveal_type(val) # str else: reveal_type(val) # int ``` I've implemented this proposal in the latest published version of pyright (1.1.202) so folks can experiment with it and see if they like it. If there's general consensus that it's the right approach, I can file an amendment for the existing PEP 647 to include this functionality. It was trivial to add to pyright, so I'm optimistic that it would likewise be easy to add to the other type checkers. Another common request for PEP 647 is the desire for an "assert" form of TypeGuard — a way to indicate that a function performs runtime validation of a type, raising an exception if the type is incorrect. It occurred to me that this two-argument form of `TypeGuard` could also be used to handle this use case. The second argument would be specified as a `NoReturn`. I've provisionally implemented this in pyright as well (although it's not in the currently-published version — you'll need to wait until 1.1.203 is published). Here's what this would look like: ```python def validate_sequence(val: Sequence[_T | None]) -> TypeGuard[Sequence[_T], NoReturn]: """Verifies that the sequence contains no None values""" if len([x for x in val if x is not None]) > 0: raise Exception() return True def func(val: Sequence[int | None]): validate_sequence(val) reveal_type(val) # Sequence[int] ``` I'm interested in input on these proposals. -Eric -- Eric Traut Contributor to Pyright & Pylance Microsoft

7 8

Any way to express that a dict is expected to have a key(s) but don't care about other keys?
by Brett Cannon June 19, 2023

June 19, 2023

Looking at TypedDict it seems that it does not like the idea of superfluous keys existing in a dict. In my case I have a REST call returning JSON for an error and all I'm guaranteed is to get an "error" key. But there may be extra keys that provide more details about the specific error. Unfortunately I don't know the exhaustive list of keys so I can't use a TypedDict with `totality == False` to try to be complete. I can't think of any way to somehow say "require/expect this one key, but other keys are OK". Am I missing anything that would let me do this?

17 35

Runtime Access to Type Parameters
by Saul Shanabrook June 7, 2023

June 7, 2023

I would like to propose being able to access, at runtime, the type parameters in classmethods and in constructors. I wrote up a draft PEP on this to capture the thinking here: https://github.com/saulshanabrook/peps/blob/master/pep-9999.md It seems easier to add them to classmethods, so even that addition alone would be very welcome! It could be added to Guido's existing draft PR for pep 585, by making a small change in the getattr function (https://github.com/python/cpython/pull/18239/files#diff-a34ae826f869897e56e…), to first do a `__getattribute__` and check if the result is a descriptor (has a `__get__` attribute), and if so passing the generic class itself in as the class, instead of the origin class. I wrote up a little example of that in the PEP. To make it available in the constructor, I proposed adding a global function `get_parameters` to `typing` which returns the parameters in the constructor. I also provide a little mock implementation of that. Note that work is only for custom classes which inherit from `typing.Generic` not for any built in collections.

5 6

Extending published stubs
by Irv Lustig April 26, 2023

April 26, 2023

I'm the leader of the pandas-stubs project. In pandas, users can extend the library by creating their own accessor via `(a)pd.api.extensions.register_dataframe_accessor` (see https://pandas.pydata.org/docs/reference/api/pandas.api.extensions.register…). So for a `DataFrame`, if you do `(a)pd.api.extensions.register_dataframe_accessor("xyz")`, you now have `DataFrame.xyz` returning the class you annotated. Now suppose you want to create a stub for your new accessor, that would extend the existing pandas-stubs. AFAIK, there isn't a way to do something like this in a stub: ``` from pandas import DataFrame @typing.extend class DataFrame: def xyz(self) -> MyXyzClass: ... ``` The idea here is that there is a class (in this case, `DataFrame`) that already has stubs, and you want to add a method to it. Has this idea been discussed anywhere?

6 11

Support Algebraic Data Types with @sealed
by John Hagen March 20, 2023

March 20, 2023

The original (superseded) PEP 622 proposed adding a @sealed decorator so that users could define algebraic data types (ADTs) that static type checkers could verify are `match`ed exhaustively: - https://peps.python.org/pep-0622/#sealed-classes-as-algebraic-data-types There is a somewhat fairly-upvoted question about ADTs in Python, indicating interest in this area: - https://stackoverflow.com/questions/16258553 @sealed would be very valuable towards making ADT usage within Python more type-safe. Is there any historical discussion about why @sealed was dropped from the final pattern matching PEP? What would be the next steps needed to push this forward? Would writing a new PEP be the next step?

15 32

PyCon 2023 Typing Summit: Interest form
by S Pradeep Kumar March 16, 2023

March 16, 2023

Hello all, PyCon 2023 is just a few months out. Jelle and I are looking forward to organizing the Typing Summit this year. We plan to be in-person in Salt Lake City, as we did last year. We have confirmed the Typing Summit with PyCon and will announce the exact date soon (tentatively a day before the main conference talks). We will try to record the event for those who cannot make it. For those who haven't attended before, the Typing Summit is a 3-4 hour event with a series of presentations and group discussions related to type checking. You can find the 2022 summit here: https://youtu.be/BNTkWQfqP_c If you are interested in attending, please fill out this form: https://forms.gle/yv1WnDoAVscg21vW8. This way, we can get a sense of the expected number of attendees and the topics you want to hear about. In a few weeks, we will send out another mail to typing-sig calling for presenters. Let us know if you have any questions. Best, Jelle Zijlstra Pradeep Kumar Srinivasan

1 2

Opened and changed typing issues week 2023-W08
by Typing Bot Feb. 26, 2023

Feb. 26, 2023

The following is an overview of all issues and pull requests in the typing repository on GitHub with the label 'topic: feature' that were opened or updated last week, excluding closed issues. --------------------------------------------------- The following issues and pull requests were updated last week: #256 Possible to distinguish between Sequence[str]/Iterable[str] and str? opened by @jtatum https://github.com/python/typing/issues/256 #1160 Allow `float("inf")` and `float("-inf")` in literals opened by @antonagestam https://github.com/python/typing/issues/1160 #1273 Type lookup table for generics opened by @jonathanslenders https://github.com/python/typing/issues/1273 --------------------------------------------------- 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

Is it possible to annotate decorators that work on both functions and methods?
by Neil Girdhar Feb. 26, 2023

Feb. 26, 2023

It appears to be impossible to perfectly annotation a decorator that works on both functions or methods. And also, it's particularly hard to implement the __get__ method. I propose adding typing.PositionalSubstitute to resolve this. Consider: from typing import Callable, Generic, Protocol, TypeVar, overload, Any from typing_extensions import ParamSpec, Self, Concatenate V_co = TypeVar("V_co", covariant=True) U = TypeVar("U", contravariant=True) P = ParamSpec("P") class Wrapped(Protocol, Generic[P, V_co]): def __call__(self, /, *args: P.args, **kwargs: P.kwargs) -> V_co: ... class MethodWrapped(Protocol, Generic[U, P, V_co]): def __get__(self, instance: Any, owner: Any = None) -> Wrapped[P, V_co]: ... @overload def jit(f: Callable[Concatenate[U, P], V_co]) -> MethodWrapped[U, P, V_co]: # type: ignore pass @overload def jit(f: Callable[P, V_co]) -> Wrapped[P, V_co]: # pyright: ignore pass def jit(f: Callable[..., Any]) -> Any: pass class X: @jit def f(self, x: int) -> None: pass @jit def g(x: int, y: float) -> None: pass x = X() x.f(3) x.f(x=3) g(3, 4.2) g(x=3, y=4.2) # Fails! reveal_type(x.f) reveal_type(g.__call__) We can't seem to deal with the method case alongside the function case. Here's the proposed solution: class Wrapped(Protocol, Generic[P, V_co]): def __call__(self, *args: P.args, **kwargs: P.kwargs) -> V_co: ... def __get__(self, instance: U, owner: Any = None ) -> Wrapped[PositionalSubstitute[P, U], V_co]: ... # Much easier! def jit(f: Callable[P, V_co]) -> Wrapped[P, V_co]: # pyright: ignore pass # No overloads! The idea is that PositionalSubstitute takes a ParamSpec argument and returns it less that ParamSpec's first positional parameter. It verifies that this removed parameter matches its second argument. This could be generalized to substitute with tuples (or ParamSpec.args), or generalized to support multiple applications (taking a tuple argument as its second argument).

2 3

Should we add a contains_only type guard to the collection mixin?
by Neil Girdhar Feb. 26, 2023

Feb. 26, 2023

As type guards become more popular, this one may become extremely common: ``` _T = TypeVar("_T") class Collection: def contains_only(self, type_: Type[_T]) -> TypeGuard[Collection[_T]]: return all(isinstance(x, type_) for x in self) # usage: usernames = settings_dict['usernames'] assert isinstance(usernames, list) assert usernames.contains_only(str) # Ensure it contains only strings. assert_type(usernames, list[str]) # Should pass, but see note. ``` Would it make sense to add it to the `Collection` mixin so that it's available on all collections? Maybe `is_collection_of` would be a better name? The final check may not be easy to get working without an extra ``` assert isinstance(usernames, list) ``` in today's Pyright/MyPy. Or maybe it would be better to have this work on a `GenericAlias` of a collection? Like ```python assert list[str].typeguard(usernames) ``` The benefit of this being that generic class `G[C]` could use `C.typeguard(vaue)` in its code without knowing what `C` is. E.g. ``` class SupportsTypeguard(Protocol): @classmethod # this needs to be available on the generic alias, though def typeguard(cls) -> TypeGuard[Self]: ... C = TypeVar(C, bound=SupportsTypeguard) class G(Generic[C]): def f(self, ...) -> C: # generate a return value of unknown type assert C.typeguard(value) # Works if C is int, or list[str], or whatever else implements this interface. return value

2 2

Why is TypeGuard not a subtype of bool?
by Kevin Millikin Feb. 22, 2023

Feb. 22, 2023

PEP 647 (https://peps.python.org/pep-0647/) is very clear that TypeGuard is not a subtype of bool, but without motivation. I don't understand why. To me, it's a bool value with some extra static metadata (that it's a type guard for some type). We should always be able to statically forget about that metadata. A programmer who wants to use the result of a type guard as a bool value will have to write `True if is_str_list(xs) else False` which looks silly to me (and I would normally teach beginners is useless). From the PEP: """ This PEP introduces the symbol TypeGuard exported from the typing module. TypeGuard is a special form that accepts a single type argument. It is used to annotate the return type of a user-defined type guard function. Return statements within a type guard function should return bool values, and type checkers should verify that all return paths return a bool. In all other respects, TypeGuard is a distinct type from bool. It is not a subtype of bool. Therefore, Callable[..., TypeGuard[int]] is not assignable to Callable[..., bool]. """ I'm bothered by "in all other respects". That makes me think I could distinguish them by writing ``` def test(b: bool | TypeGuard[list[str]]): if not isinstance(b, bool): # This is reachable and b has type TypeGuard[list[str]]. ``` And I would expect it to work to distinguish type guards from "other" bool values at runtime: ``` guard = is_str_list(xs) test(guard) # Should hit the TypeGuard branch. ``` But that requires that an implementation will have to somehow tag type guards at runtime, and I don't think any implementation is actually going to want to do that. -- [image: logo] Kevin Millikin Software Engineer kmillikin(a)deepmind.com If you received this email in error, please do not forward it to anyone else (it may contain confidential or privileged information), erase all copies and attachments, and let me know that it has gone to the wrong person.

3 15

Compatibility rules for method overrides
by Steven Troxler Feb. 21, 2023

Feb. 21, 2023

In PEP 698 (regarding @typing.override), we had a section clarifying that this PEP does *not* add any additional rules about ensuring that subclass methods have type signatures that are compatible with those of superclasses [1]. The way we phrased it was to say that this was already required. After we requested review from the SC, Brett Cannon pointed out, correctly, that in fact no existing PEP says this should be true [2]. All of the existing type checkers do require at least some compatibility, because to not do so would be unsound - for example the following code will fail and we would want type checkers to catch it: ```python class A: def f(self) -> int: return 5 class B: # incompatible override, return class is not a subtype of the return class `int` in parent method def f(self) -> str: return "5" a: A = B() x = 5 + a.f() # Runtime type error! ``` The rule of thumb for compatibility is that all legal function calls for the parent method should be legal, and the output of the subclass method should have a value that is of the type of the parent method return annotation. This implies several specific rules, depending exactly how many edge cases a particular type checker wants to catch - the ones I can think of off the top of my head being: (a) the return annotation on a subclass method should be a subtype of that on the parent class (b) for any parameter in the parent signature, the subclass parameter should be a supertype of what is declared in the parent method (c) named parameter names should not change, that would invalidate some calls (d) new positional or named parameters should have default values, otherwise you could get missing argument errors (e) if the parent type has a *args, then new positional-only / named params must be a supertype of the *args type (f) if the parent type has a *kwargs, then new named / keyword-only params must be a supertype of the *kwargs type I'm not sure whether all type checkers enforce all these rules - some of them (especially the *args and **kwargs limitations) might be obtrusive enough to merit trading off soundness. But my main question is simply: should we try to declare this behavior somewhere in the PEPs repo? We could potentially formalize the rule in a new PEP, or perhaps just add a note to PEP 484 (I believe this is Guido's preference, I'm not sure how clarifying existing PEPs works but that does seem better than a new PEP to me). -------------- [1] PEP 698 compatibility section, prior to Brett's objection: https://github.com/python/peps/blob/c34268dd5b7a2344437ea2785bbb2e1340226b0… [2] Discussion in steering-council issue regarding compatibility: https://github.com/python/steering-council/issues/160

3 2

Macros in type checking contexts
by Tin Tvrtković Feb. 20, 2023

Feb. 20, 2023

Hello friends, I was curious whether macro systems have ever been brought up in type checking contexts for Python? Some cursory research turned up MacroPy and PEP 638 (Syntactic Macros), but these ideas, as far as I can tell, work inside the interpreter, at import time. But what if we had macros that did their processing before, at 'typechecking' time? The final, processed output is then fed into the typechecker. For example, if attrs and dataclasses were implemented as these 'typechecking' macros, they wouldn't need plugins or PEP 681. Typecheckers could implement support for the macro system and let the community innovate (as we do in the runtime context already). Ideally other tools, like Mypyc, could also operate on the output of this phase. Both MacroPy and PEP 638 claim to operate on AST nodes. Would that even be compatible with Mypy/Pyright/Pyre, or do these require a different representation? As I get ready to do some more work on the Mypy attrs plugin, I feel like we (the typing community) are stuck in a local maximum and unless we have a fundamental rethink, typed Python won't be what it could be. I'm curious to hear what the community thinks of an approach like this.

2 1

Re: TypeGuard is covariant, right?
by Morgan Bartholomew Feb. 20, 2023

Feb. 20, 2023

Unfortunately `TypeGuard` is bivariant. https://github.com/python/mypy/issues/11230 https://github.com/python/mypy/issues/11229

1 0

Expressing type relationships between keys and values of a dict
by Oscar Benjamin Feb. 20, 2023

Feb. 20, 2023

Hi all, I have some code that works relatively naturally as untyped Python code and is type safe at runtime but I can't see how to make that be understood by a static type checker. I'm just wondering if anyone has a better idea than just using Any or type:ignore. My actual code is much more complicated but I have a simple demonstration below. The crux of the issue is that I have things like dicts where there are typing relationships between the keys and the values like: function_map = { Key[T1]: Callable[[T1], R], Key[T2]: Callable[[T2], R], ... } The relationships between the keys and values of this dictionary mean that at runtime a lookup should return a function of the correct type. I can't seem to find any way to express this with type annotations though. Ideally I would want for: 1. A type checker to be able to verify the relationships between the keys and values of the dictionary. 2. A type checker to understand these relationships when function_map is used to lookup a function and call it. After looking a bit I'm fairly sure that it is not possible to make this work with an actual dict. I would be happy to try any suggestions though. Here is demonstration code: ================================== from typing import Generic, TypeVar, Hashable, Callable, Any, cast T = TypeVar('T', bound=Hashable, covariant=True) class Key(Generic[T]): def __init__(self, name: str): self.name = name class Atom(Generic[T]): def __init__(self, key: Key[T], value: T): self.key = key self.value = value # A key for Objects with int as internal value # and a function int -> float number_key: Key[int] = Key('number') number_func: Callable[[int], float] = lambda v: float(v)**2 # A key for Objects with str as internal value # and a function str -> float symbol_key: Key[str] = Key('symbol') symbol_func: Callable[[str], float] = lambda v: float(len(v)) # A different key for Objects also having str as internal value # but a different associated function. function_key: Key[str] = Key('function') function_func: Callable[[str], float] = lambda v: -1 # No way to annotate this because number_func and symbol_func # are incompatible. function_map = { number_key: number_func, symbol_key: symbol_func, function_key: function_func, } objects: list[Atom[Hashable]] = [Atom(number_key, 2), Atom(symbol_key, 'foo')] for obj in objects: func = function_map[obj.key] result: float = func(obj.value) print(result) ================================== Here mypy gives: $ mypy --strict demo2.py demo2.py:41:21: error: Cannot call function of unknown type [operator] result: float = func(obj.value) ^~~~~~~~~~~~~~~ Found 1 error in 1 file (checked 1 source file) The error is because I haven't annotated function_map and mypy cannot figure out a usable type for it. Using reveal_type(function_map) gives: builtins.dict[demo2.Key[builtins.object], builtins.function] There doesn't seem to be any way that I can annotate function_map without using Any and/or cast. Does anyone have a better idea how to annotate this? -- Oscar

2 2

TypeGuard is covariant, right?
by Kevin Millikin Feb. 20, 2023

Feb. 20, 2023

PEP 647 (https://peps.python.org/pep-0647/) doesn't mention the variance of `TypeGuard` as far as I can tell. I think it's obviously covariant. If I want a `Callable[[object], TypeGuard[float]]` then you can give me a `Callable[[object], TypeGuard[int]]`. If it returns True then the argument is definitely a `float` (in fact, it's an `int`). Mypy and pyright appear to agree. This is the simplest explanation of why `TypeGuard` doesn't narrow in the negative case. Your `float` type guard might actually be an `int` one. -- [image: logo] Kevin Millikin Software Engineer kmillikin(a)deepmind.com If you received this email in error, please do not forward it to anyone else (it may contain confidential or privileged information), erase all copies and attachments, and let me know that it has gone to the wrong person.

1 0

Opened and changed typing issues week 2023-W07
by Typing Bot Feb. 19, 2023

Feb. 19, 2023

The following is an overview of all issues and pull requests in the typing repository on GitHub with the label 'topic: feature' that were opened or updated last week, excluding closed issues. --------------------------------------------------- The following issues and pull requests were updated last week: #213 Introduce an Intersection opened by @ilevkivskyi https://github.com/python/typing/issues/213 #256 Possible to distinguish between Sequence[str]/Iterable[str] and str? opened by @jtatum https://github.com/python/typing/issues/256 --------------------------------------------------- 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

typing-extensions 4.5.0 released
by Jelle Zijlstra Feb. 14, 2023

Feb. 14, 2023

I just released typing-extensions 4.5.0. The release adds support for @deprecated (PEP 702) and includes various other bug fixes and improvements: - Runtime support for PEP 702, adding `typing_extensions.deprecated`. Patch by Jelle Zijlstra. - Add better default value for TypeVar `default` parameter, PEP 696. Enables runtime check if `None` was passed as default. Patch by Marc Mueller (@cdce8p). - The `(a)typing_extensions.override` decorator now sets the `.__override__` attribute. Patch by Steven Troxler. - Fix `get_type_hints()` on cross-module inherited `TypedDict` in 3.9 and 3.10. Patch by Carl Meyer. - Add `frozen_default` parameter on `dataclass_transform`. Patch by Erik De Bonte.

1 0

Could we expose DataclassInstance?
by Neil Girdhar Feb. 14, 2023

Feb. 14, 2023

Currently, pyright checks that only dataclasses are passed to `dataclasses.field`. A dataclass is defined to match the protocol: ``` class DataclassInstance(Protocol): __dataclass_fields__: ClassVar[dict[str, dataclasses.Field[Any]]] ``` This is good enough for users, but would it be more convenient to expose `DataclassInstance` in typing-extensions and ultimately typing?

3 4

Opened and changed typing issues week 2023-W06
by Typing Bot Feb. 12, 2023

Feb. 12, 2023

The following is an overview of all issues and pull requests in the typing repository on GitHub with the label 'topic: feature' that were opened or updated last week, excluding closed issues. --------------------------------------------------- The following issues and pull requests were updated last week: #213 Introduce an Intersection opened by @ilevkivskyi https://github.com/python/typing/issues/213 #256 Possible to distinguish between Sequence[str]/Iterable[str] and str? opened by @jtatum https://github.com/python/typing/issues/256 #685 Record Types opened by @saulshanabrook https://github.com/python/typing/issues/685 --------------------------------------------------- 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

Opened and changed typing issues week 2023-W05
by Typing Bot Feb. 5, 2023

Feb. 5, 2023

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 Feb. 2, 2023

Feb. 2, 2023

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 Feb. 2, 2023

Feb. 2, 2023

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