From 922b69b6d5f00475a7d989a4c9f10555e8d51298 Mon Sep 17 00:00:00 2001 From: "Michael J. Sullivan" Date: Wed, 21 Oct 2026 11:55:33 -0700 Subject: [PATCH 1/3] PEP 827: Minor updates * Add a note about the goal of FromUnion * A note about property * Some "open questions" notes about intersections and GetMemberType --- peps/pep-0827.rst | 19 +++++++++++++++++++ 1 file changed, 19 insertions(+) diff --git a/peps/pep-0827.rst b/peps/pep-0827.rst index 656c0ea7299..5155ddc2fe4 100644 --- a/peps/pep-0827.rst +++ b/peps/pep-0827.rst @@ -665,6 +665,11 @@ Union processing * ``FromUnion[T]``: Returns a tuple containing all of the union elements, or a 1-ary tuple containing T if it is not a union. + The goal here is to make it possible to lift operations over + unions. Care ought to be taken when using this, since the particular + order of elements is not specified; typically the result should be + aggregated into another union. + * ``Union[*Ts]``: ``Union`` will become able to take variadic arguments, so that it can take unpacked comprehension arguments. @@ -677,6 +682,11 @@ Object inspection * ``Members[T]``: produces a ``tuple`` of ``Member`` types describing the members (attributes and methods) of class or typed dict ``T``. + Properties should be returned as ``property`` types, which we should + to make generic and parameterized over both the getter and setter + types. (Under discussion in `typeshed issue #4731 + `__) + In order to allow typechecking time and runtime evaluation to coincide more closely, **only members with explicit type annotations are included**. (This is intended to also exclude unannotated @@ -1846,6 +1856,15 @@ Open Issues Arguably, though, we would like ``tuple[Any | None, ...]`` as the result, which would require some more careful thought to specify. +* Would adding intersection types conflict with any of this, if they + are added? Would it be sufficient to add ``FromIntersection`` to + deal with it, in addition to specifying how the existing operators + should handle it? + +* Should ``GetMemberType`` follow the descriptor protocol, + ``__getattr__``, etc? (Currently the behavior is for it to + behave mostly like ``GetMember[T, S].type``.) + Acknowledgements ================ From a6ba861b924710442bb96e937033c54e3b9b9914 Mon Sep 17 00:00:00 2001 From: "Michael J. Sullivan" Date: Mon, 26 Oct 2026 11:56:47 -0700 Subject: [PATCH 2/3] Update peps/pep-0827.rst Co-authored-by: Jelle Zijlstra --- peps/pep-0827.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/peps/pep-0827.rst b/peps/pep-0827.rst index 5155ddc2fe4..9ecd8b44eb6 100644 --- a/peps/pep-0827.rst +++ b/peps/pep-0827.rst @@ -683,7 +683,7 @@ Object inspection the members (attributes and methods) of class or typed dict ``T``. Properties should be returned as ``property`` types, which we should - to make generic and parameterized over both the getter and setter + make generic and parameterized over both the getter and setter types. (Under discussion in `typeshed issue #4731 `__) From 488df4ad54f487a079b0d5f07a1562f7ad629c21 Mon Sep 17 00:00:00 2001 From: "Michael J. Sullivan" Date: Mon, 26 Oct 2026 12:33:17 -0700 Subject: [PATCH 3/3] adjust intersection notes, call for simplfying unions --- peps/pep-0827.rst | 20 ++++++++++++++------ 1 file changed, 14 insertions(+), 6 deletions(-) diff --git a/peps/pep-0827.rst b/peps/pep-0827.rst index 9ecd8b44eb6..1dbf95d4031 100644 --- a/peps/pep-0827.rst +++ b/peps/pep-0827.rst @@ -665,10 +665,14 @@ Union processing * ``FromUnion[T]``: Returns a tuple containing all of the union elements, or a 1-ary tuple containing T if it is not a union. + The union should first be simplified by removing elements that are + subtypes of other elements, but *not* by replacing ``Literal[True, + False]`` with ``bool`` or vice-versa or similar. + The goal here is to make it possible to lift operations over unions. Care ought to be taken when using this, since the particular - order of elements is not specified; typically the result should be - aggregated into another union. + order of elements is not specified; typically the result of the iteration + should be unpacked into another union immediately. * ``Union[*Ts]``: ``Union`` will become able to take variadic arguments, so that it can take unpacked comprehension arguments. @@ -1856,10 +1860,14 @@ Open Issues Arguably, though, we would like ``tuple[Any | None, ...]`` as the result, which would require some more careful thought to specify. -* Would adding intersection types conflict with any of this, if they - are added? Would it be sufficient to add ``FromIntersection`` to - deal with it, in addition to specifying how the existing operators - should handle it? +* Would intersection types conflict with any of this, if they are + added? Would it be sufficient to just specify how existing operators + should handle it (probably including that intersections should be + distributed over unions when doing ``FromUnion``, I'd guess, like TS + does for conditional types)? We could potentially add + ``FromIntersection``, but intersections simplify aggressively and it + is not clear it would be sensical. TypeScript does not have an + equivalent. * Should ``GetMemberType`` follow the descriptor protocol, ``__getattr__``, etc? (Currently the behavior is for it to