Mailman 3 March 2022 - Typing-sig

Re: Typing Meetup
by S Pradeep Kumar 19 Sep '23

19 Sep '23

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 04 Aug '23

04 Aug '23

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 19 Jun '23

19 Jun '23

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 07 Jun '23

07 Jun '23

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

Defaults for TypeVar-likes
by James H-B 03 Nov '22

03 Nov '22

I've been toying with the idea of writting a PEP for this long requested feature (https://github.com/python/typing/issues/307). I've got a preliminary draft of it with the motivation and a specification for the feature. In short features like ```py T = TypeVar("T", default=int) # This means that if no type is specified T = int @dataclass class Box(Generic[T]): value: T | None = None reveal_type(Box()) # type is Box[int] reveal_type(Box(value="Hello World!")) # type is Box[str] ``` would be supported as would ```py YieldT = TypeVar("YieldT") SendT = TypeVar("SendT", default=None) ReturnT = TypeVar("ReturnT", default=None) class Generator(Generic[YieldT, SendT, ReturnT]): ... Generator[int] == Generator[int, None] == Generator[int, None, None] ``` Feedback and any questions on this would be very appreciated. https://gist.github.com/Gobot1234/8c9bfe8eb88f5ad42bf69b6f118033a7 Thanks, James H-B.

8 20

Explicit Type Aliases
by Shannon Zhu 17 Aug '22

17 Aug '22

Hi everyone, I’d like to continue the discussion from our last typing summit on explicit type aliases. A quick summary of the current state and the proposal -- Current state: ``` from typing import List x = List[int] # considered a type alias y : Type[List[int]] = List[int] # considered an expression z : Any # considered a type alias z : x = [] # fine z : y = [] # invalid type error ``` Proposal (with explicit aliases): ``` from typing import List, TypeAlias x = TypeAlias[List[int]] # considered a type alias y = List[int] # considered an expression z : Any # considered an expression z = TypeAlias[Any] # considered a type alias reveal_type(x) # Type[List[int]] reveal_type(y) # Any (return type of __getitem__) z : x = [] # fine z : y = [] # invalid type error ``` Some of the benefits we’re hoping to gain from explicit type aliases: * Clearly distinguish between an unannotated global assignment and a type alias, especially when parsing forward-referencing string annotations. * Avoid the confusing case of type aliases in which some part of the type is invalid or undefined. This would facilitate warnings on invalid types at the alias definition rather than later on when the alias is used. * Make valid and invalid types more intuitive to Python programmers by shifting from delineation of non-aliases with a meta annotation toward delineation of aliases with `TypeAlias`. * Remove special treatment of values annotated as `Any`, which currently break all type aliasing rules. This will also allow us to clean up some of the distinctions we maintain between unannotated values and explicit Anys. Note: We also considered denoting the alias as an annotation (e.g. `x: TypeAlias = int`) as an alternative to the syntax above. I’m interested to hear your thoughts and suggestions on making type aliasing explicit going forward – we’d like to start implementing a version of this in Pyre soon! Shannon

7 10

Dataclass Transform draft PEP
by Erik De Bonte 21 Apr '22

21 Apr '22

I've created a draft PEP for the "Dataclass Transforms" concept that Eric Traut presented at the December 1st Typing SIG meetup. Feedback is welcome! https://github.com/debonte/peps/blob/dataclass_transforms/pep-9999.rst Thanks, Erik

12 52

Syntax for inline-definition of TypeVar
by Sebastian Rittau 18 Apr '22

18 Apr '22

After the discussion on type var defaults, Guido and I had a short discussion about a potential inline-definition syntax for type vars. Such a syntax has a few advantages over the definition using TypeVar: * The type vars would be defined close to where they are actually used. * Type vars would not leak their name into the module-global scope. * Removes the duplication from TypeVar: _T = TypeVar("_T") * This is in line with what other languages are doing and so more familiar for developers coming from other languages. Even if we implement an inline syntax, TypeVar should not be deprecated as it's still quite useful for defining re-usable type vars like typing.AnyStr. Here are a few proposals we came up with. Inline syntax using square brackets ===================== class C[T, S]: def foo[R=int](self) -> R: pass Some ideas how we could express upper bounds, constraints, and variance: * Upper bounds: [R(Base1 | Base2)] or [R from Base1 | Base2]. * Constraints: [R as Base1 | Base2] * Variance: [R(covariant=True)] Advantages: * Similar syntax to existing generics syntax. * Used by languages such as Go and Scala. Disadvantages: * Square brackets are already used for indexes/slices and generics. * We have a bit of a "bracket hell", which does not help readability: def foo[F=dict[str, Callable[[int], object]]](): pass Inline syntax using angle brackets ===================== class C<T, S>: def foo<R>(self) -> R: pass Advantages: * Angle brackets are currently unused in Python and lower than/greater than is not used within type context. * Using angle brackets could reduce "bracket hell". * Used by languages like C++, Java, C#, TypeScript, Delphi, so should be fairly similar to developers coming from popular languages. Disadvantages: * Slightly inconsistent with existing generic syntax. Decorators ======= @typevar("T") @typevar("S") class C: @typevar("R", default=int) def foo(self) -> R: pass Advantages: * Doesn't require syntax changes to Python. * Very readable (in my opinion), because it has one type var per line, especially with more complex type vars. * Is defined exactly like a TypeVar(), but without assigning it to a name. * Flexible and extensible as it's using regular decorator syntax. * Backwards compatible as it could be added to typing_extensions. Disadvantages: * More verbose than the other suggestions, especially when using simple type vars. * Non-standard syntax, compared to other languages. * Currently requires either quoted types or "from __future__ import annotations". ------------------------- My personal favorite is the decorator syntax, for all the advantages listed. The disadvantages seem minor to me or temporary. Being more verbose makes is actually more readable. When writing TypeScript, I often have monsters like this: function createReactStore< S, A extends Action = AnyAction, E = undefined, >( someArguments: ... ) { // ... } I believe that the Python equivalent using decorator would be more readable: @typevar("S") @typevar("A", bound=Action, default=AnyAction) @typevar("E", default=object) def createReactStore( someArguments: ... ): ... - Sebastian

11 21

Status of PEP 645? (Allow writing optional types as x?)
by David Foster 15 Apr '22

15 Apr '22

The typing-related PEP 645 - which introduces the syntax `T?` to mean `Optional[T]` - only has a single substantial related commit in the PEPs repo - the commit introducing the PEP (in Nov 2020) - and no discussions thread that I can find (on typing-sig or elsewhere). I'm personally quite interested in the potential capability to quickly signify `Optional[T]` since it is something I do a lot. What is the status of this PEP? Deferred for now? Withdrawn in favor of `T|None` syntax?† Something else? -- David Foster | Seattle, WA, USA Contributor to TypedDict, mypy, and Python's typing system † Through the grapevine I've been inferring that folks have been gravitating toward the slightly-shorter `T|None` syntax to spell `Optional[T]` in the meantime, and I even mention that spelling in my own PEP 655 (Required[]) [1] [1]: https://peps.python.org/pep-0655/#how-to-teach-this

4 5

SC requests for typing-sig: specifications & delegation
by encukou＠gmail.com 15 Apr '22

15 Apr '22

Dear typing-sig, Typing-related PEPs are becoming more common, and we'd like to propose some changes to how they are handled. First, we feel that it is time to convert PEPs (proposals) to specifications. We're getting to the point where we might refer to a feature as “PEP 589 as amended by PEP 655”. To understand a feature, users (and implementers of typing tools) must read through proposal documents that contain motivation, discussion, and sometimes even information that's obsolete today. The use of PEP numbers in everyday communication makes the field even less accessible to outsiders. The Python Packaging Authority (PyPA) used to be in a similar situation, and moved to a model of [specifications], which contain current information, and PEPs as change proposals, which contain a summary of each change and the reasoning (motivation, rationale, discussion summary) for each change. The work of converting existing PEPs to spec documents is not done, but the eventual goal is clear. We ask you to consider adopting a similar model. [specifications]: https://packaging.python.org/en/latest/specifications/ Second, we'd like to see some kind of typing-sig delegation. For PEPs like 655 (Marking individual TypedDict items as required or potentially-missing), which only affect typing.py and external tools, consensus on typing-sig is by far the most important consideration for accepting or rejecting a PEP. If you could appoint a person (or committee) you trust to speak on behalf of typing-sig -- that is, seek consensus on the list and fairly summarize it -- it would simplify the decision process. It could even be the first step toward delegating typing-related PEPs entirely. Happy typing! – Petr, on behalf of the Steering Council

6 11