Mailman 3 September 2021 - Typing-sig

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

Explicit Type Aliases
by Shannon Zhu Aug. 17, 2022

Aug. 17, 2022

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

PEP 655: Marking individual TypedDict items as required or potentially-missing
by David Foster Feb. 23, 2022

Feb. 23, 2022

The new syntax Required[...] and NotRequired[...] for marking individual keys of a TypedDict has now been formally proposed as a draft PEP. Please see the latest text at the bottom of this email, or online at: https://www.python.org/dev/peps/pep-0655/ Comments welcome. :) Meanwhile I'll proceed to implement this syntax in mypy. -- David Foster | Seattle, WA, USA Contributor to TypedDict support for mypy >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> PEP: 655 Title: Marking individual TypedDict items as required or potentially-missing Author: David Foster <david at dafoster.net> Sponsor: Guido van Rossum <guido at python.org> Discussions-To: typing-sig at python.org Status: Draft Type: Standards Track Content-Type: text/x-rst Requires: 604 Created: 30-Jan-2021 Python-Version: 3.10 Post-History: 31-Jan-2021, 11-Feb-2021, 20-Feb-2021, 26-Feb-2021 Abstract ======== `PEP 589 <https://www.python.org/dev/peps/pep-0589/>`__ defines syntax for declaring a TypedDict with all required keys and syntax for defining a TypedDict with `all potentially-missing keys <https://www.python.org/dev/peps/pep-0589/#totality>`__ however it does not provide any syntax to declare some keys as required and others as potentially-missing. This PEP introduces two new syntaxes: ``Required[...]`` which can be used on individual items of a TypedDict to mark them as required, and ``NotRequired[...]`` which can be used on individual items to mark them as potentially-missing. Motivation ========== It is not uncommon to want to define a TypedDict with some keys that are required and others that are potentially-missing. Currently the only way to define such a TypedDict is to declare one TypedDict with one value for ``total`` and then inherit it from another TypedDict with a different value for ``total``: :: class _MovieBase(TypedDict): # implicitly total=True title: str class Movie(_MovieBase, total=False): year: int Having to declare two different TypedDict types for this purpose is cumbersome. Rationale ========= One might think it unusual to propose syntax that prioritizes marking *required* keys rather than syntax for *potentially-missing* keys, as is customary in other languages like TypeScript: :: interface Movie { title: string; year?: number; // ? marks potentially-missing keys } The difficulty is that the best word for marking a potentially-missing key, ``Optional[...]``, is already used in Python for a completely different purpose: marking values that could be either of a particular type or ``None``. In particular the following does not work: :: class Movie(TypedDict): ... year: Optional[int] # means int|None, not potentially-missing! Attempting to use any synonym of “optional” to mark potentially-missing keys (like ``Missing[...]``) would be too similar to ``Optional[...]`` and be easy to confuse with it. Thus it was decided to focus on positive-form phrasing for required keys instead, which is straightforward to spell as ``Required[...]``. Nevertheless it is common for folks wanting to extend a regular (``total=True``) TypedDict to only want to add a small number of potentially-missing keys, which necessitates a way to mark keys that are *not* required and potentially-missing, and so we also allow the ``NotRequired[...]`` form for that case. Specification ============= The ``typing.Required`` type qualifier is used to indicate that a variable declared in a TypedDict definition is a required key: :: class Movie(TypedDict, total=False): title: Required[str] year: int Additionally the ``typing.NotRequired`` type qualifier is used to indicate that a variable declared in a TypedDict definition is a potentially-missing key: :: class Movie(TypedDict): # implicitly total=True title: str year: NotRequired[int] It is an error to use ``Required[...]`` or ``NotRequired[...]`` in any location that is not an item of a TypedDict. It is valid to use ``Required[...]`` and ``NotRequired[...]`` even for items where it is redundant, to enable additional explicitness if desired: :: class Movie(TypedDict): title: Required[str] # redundant year: NotRequired[int] Backwards Compatibility ======================= No backward incompatible changes are made by this PEP. How to Teach This ================= To define a TypedDict where most keys are required and some are potentially-missing, define a single TypedDict as normal and mark those few keys that are potentially-missing with ``NotRequired[...]``. To define a TypedDict where most keys are potentially-missing and a few are required, define a ``total=False`` TypedDict and mark those few keys that are required with ``Required[...]``. If some items accept ``None`` in addition to a regular value, it is recommended that the ``TYPE|None`` syntax be preferred over ``Optional[TYPE]`` for marking such item values, to avoid using ``Required[...]`` or ``NotRequired[...]`` alongside ``Optional[...]`` within the same TypedDict definition: Yes: :: from __future__ import annotations # for Python 3.7-3.9 class Dog(TypedDict): name: str owner: NotRequired[str|None] Avoid (unless Python 3.5-3.6): :: class Dog(TypedDict): name: str # ick; avoid using both Optional and NotRequired owner: NotRequired[Optional[str]] Reference Implementation ======================== The goal is to be able to make the following statement: The `mypy <http://www.mypy-lang.org/>`__ type checker supports ``Required`` and ``NotRequired``. A reference implementation of the runtime component is provided in the `typing_extensions <https://github.com/python/typing/tree/master/typing_extensions>`__ module. The mypy implementation is currently still being worked on. Rejected Ideas ============== Special syntax around the *key* of a TypedDict item --------------------------------------------------- :: class MyThing(TypedDict): opt1?: str # may not exist, but if exists, value is string opt2: Optional[str] # always exists, but may have null value or: :: class MyThing(TypedDict): Optional[opt1]: str # may not exist, but if exists, value is string opt2: Optional[str] # always exists, but may have null value These syntaxes would require Python grammar changes and it is not believed that marking TypedDict items as required or potentially-missing would meet the high bar required to make such grammar changes. Also, “let’s just not put funny syntax before the colon.” [1]_ Marking required or potentially-missing keys with an operator ------------------------------------------------------------- We could use unary ``+`` as shorthand to mark a required key, unary ``-`` to mark a potentially-missing key, or unary ``~`` to mark a key with opposite-of-normal totality: :: class MyThing(TypedDict, total=False): req1: +int # + means a required key, or Required[...] opt1: str req2: +float class MyThing(TypedDict): req1: int opt1: -str # - means a potentially-missing key, or NotRequired[...] req2: float class MyThing(TypedDict): req1: int opt1: ~str # ~ means a opposite-of-normal-totality key req2: float Such operators could be implemented on ``type`` via the ``__pos__``, ``__neg__`` and ``__invert__`` special methods without modifying the grammar. It was decided that it would be prudent to introduce longform syntax (i.e. ``Required[...]`` and ``NotRequired[...]``) before introducing any shortform syntax. Future PEPs may reconsider introducing this or other shortform syntax options. Marking absence of a value with a special constant -------------------------------------------------- We could introduce a new type-level constant which signals the absence of a value when used as a union member, similar to JavaScript’s ``undefined`` type, perhaps called ``Missing``: :: class MyThing(TypedDict): req1: int opt1: str|Missing req2: float Such a ``Missing`` constant could also be used for other scenarios such as the type of a variable which is only conditionally defined: :: class MyClass: attr: int|Missing def __init__(self, set_attr: bool) -> None: if set_attr: self.attr = 10 :: def foo(set_attr: bool) -> None: if set_attr: attr = 10 reveal_type(attr) # int|Missing Misalignment with how unions apply to values '''''''''''''''''''''''''''''''''''''''''''' However this use of ``...|Missing``, equivalent to ``Union[..., Missing]``, doesn’t align well with what a union normally means: ``Union[...]`` always describes the type of a *value* that is present. By contrast missingness or non-totality is a property of a *variable* instead. Current precedent for marking properties of a variable include ``Final[...]`` and ``ClassVar[...]``, which the proposal for ``Required[...]`` is aligned with. Misalignment with how unions are subdivided ''''''''''''''''''''''''''''''''''''''''''' Furthermore the use of ``Union[..., Missing]`` doesn’t align with the usual ways that union values are broken down: Normally you can eliminate components of a union type using ``isinstance`` checks: :: class Packet: data: Union[str, bytes] def send_data(packet: Packet) -> None: if isinstance(packet.data, str): reveal_type(packet.data) # str packet_bytes = packet.data.encode('utf-8') else: reveal_type(packet.data) # bytes packet_bytes = packet.data socket.send(packet_bytes) However if we were to allow ``Union[..., Missing]`` you’d either have to eliminate the ``Missing`` case with ``hasattr`` for object attributes: :: class Packet: data: Union[str, Missing] def send_data(packet: Packet) -> None: if hasattr(packet, 'data'): reveal_type(packet.data) # str packet_bytes = packet.data.encode('utf-8') else: reveal_type(packet.data) # Missing? error? packet_bytes = b'' socket.send(packet_bytes) or a check against ``locals()`` for local variables: :: def send_data(packet_data: Optional[str]) -> None: packet_bytes: Union[str, Missing] if packet_data is not None: packet_bytes = packet.data.encode('utf-8') if 'packet_bytes' in locals(): reveal_type(packet_bytes) # bytes socket.send(packet_bytes) else: reveal_type(packet_bytes) # Missing? error? or a check via other means, such as against ``globals()`` for global variables: :: warning: Union[str, Missing] import sys if sys.version_info < (3, 6): warning = 'Your version of Python is unsupported!' if 'warning' in globals(): reveal_type(warning) # str print(warning) else: reveal_type(warning) # Missing? error? Weird and inconsistent. ``Missing`` is not really a value at all; it’s an absence of definition and such an absence should be treated specially. Difficult to implement '''''''''''''''''''''' Eric Traut from the Pyright type checker team has stated that implementing a ``Union[..., Missing]``-style syntax would be difficult. [2]_ Introduces a second null-like value into Python ''''''''''''''''''''''''''''''''''''''''''''''' Defining a new ``Missing`` type-level constant would be very close to introducing a new ``Missing`` value-level constant at runtime, creating a second null-like runtime value in addition to ``None``. Having two different null-like constants in Python (``None`` and ``Missing``) would be confusing. Many newcomers to JavaScript already have difficulty distinguishing between its analogous constants ``null`` and ``undefined``. Replace Optional with Nullable. Repurpose Optional to mean “optional item”. --------------------------------------------------------------------------- ``Optional[...]`` is too ubiquitous to deprecate. Although use of it *may* fade over time in favor of the ``T|None`` syntax specified by `PEP 604 <https://www.python.org/dev/peps/pep-0604/>`__. Change Optional to mean “optional item” in certain contexts instead of “nullable” --------------------------------------------------------------------------------- Consider the use of a special flag on a TypedDict definition to alter the interpretation of ``Optional`` inside the TypedDict to mean “optional item” rather than its usual meaning of “nullable”: :: class MyThing(TypedDict, optional_as_missing=True): req1: int opt1: Optional[str] or: :: class MyThing(TypedDict, optional_as_nullable=False): req1: int opt1: Optional[str] This would add more confusion for users because it would mean that in *some* contexts the meaning of ``Optional[...]`` is different than in other contexts, and it would be easy to overlook the flag. Various synonyms for “potentially-missing item” ----------------------------------------------- - Omittable – too easy to confuse with optional - OptionalItem, OptionalKey – two words; too easy to confuse with optional - MayExist, MissingOk – two words - Droppable – too similar to Rust’s ``Drop``, which means something different - Potential – too vague - Open – sounds like applies to an entire structure rather then to an item - Excludable - Checked References ========== .. [1] https://mail.python.org/archives/list/typing-sig@python.org/message/4I3GPIW… .. [2] https://mail.python.org/archives/list/typing-sig@python.org/message/S2VJSVG… Copyright ========= This document is placed in the public domain or under the CC0-1.0-Universal license, whichever is more permissive. .. Local Variables: mode: indented-text indent-tabs-mode: nil sentence-end-double-space: t fill-column: 70 coding: utf-8 End: <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<

10 31

Thoughts on a typing.Self?
by gobot1234yt＠gmail.com Nov. 2, 2021

Nov. 2, 2021

I would like to draft a PEP for a typing.Self class which would perform similarly to rust's Self keyword in function annotations. Examples ```python from typing import TypeVar F = TypeVar("F", bound="Foo") class Foo: def parse(self: F, data: bytes) -> F: ... return self ``` vs ```python from typing import Self class Foo: def parse(self, data: bytes) -> Self: ... return self ``` Another example of where this could be useful is classmethods: ```python class Foo: @classmethod def bar(cls: type[F], *args: Any, **kwargs: Any) -> F: return cls() ``` vs ```python class Foo: @classmethod def bar(cls, *args: Any, **kwargs: Any) -> Self: return cls() ``` Implementation wise it would be a copy of NoReturn, i.e. not subscriptable, a _SpecialForm and should only be valid as a return type. I haven't seen any discussion of the idea on the mailing list, so I wanted to run it by everyone. Thanks, James.

12 27

Meetup to discuss Callable Syntax
by S Pradeep Kumar Oct. 8, 2021

Oct. 8, 2021

Hello all, User-friendly Callable syntax is something we all want to see. However, there has been no real movement on the discussion in the last one month. People have had differing opinions based on design principles, stats, and personal experience. This has led to half a dozen proposals with some subtle and not-so-subtle differences [1]. And Guido pointed out that we want to settle on a full proposal instead of going for a partial PEP now and settling on the remaining details in a later PEP. How about we meet up over a zoom call and discuss some of the key concerns? Things proceed noticeably faster when people from the typing community are able to get in the same (virtual) room (I saw that with PEP 646 and the typing summit). We don't have to reach a consensus in the first meeting itself. It's more a way to break the deadlock and make progress. Date: 10 am San Francisco time (6 pm UK time), Monday, September 13, 2021. Date is flexible. Duration: 1 hour. If there is enough interest, I can set up the video call and share the link and agenda. If you're interested in presenting pros and cons for your favorite proposal, reply to this mail. [1]: Document containing the various proposals and use cases: https://docs.google.com/document/d/11VkNk9N8whxS1SrBv2BNN1Csl5yeTlgG7WyLrCB… -- S Pradeep Kumar

9 33

seeking feedback on a proposed deprecation library to be used at type checking time (in pytype)
by Yilei Yang Oct. 5, 2021

Oct. 5, 2021

Hi everyone, I'm working on a proposal to introduce a deprecation library. It is intended to be used at type checking time, and will be supported by pytype. The primary benefit (over DeprecationWarning at runtime) is to provide deprecation signals at static analysis time (think type checking, linting, IDE support). **The gist of the deprecation library** ============================ The gist of the deprecation library is to use a data class Deprecated wrapped in a typing.Annotated to mark variables/methods/functions as deprecated. Here are a couple of examples: # API: @dataclasses.dataclass class Deprecated: reason: str # Usages: my_constant: Annotated[int, Deprecated("my_constant is deprecated.")] = 123 def do_something(name: str, arg: Annotated[Any, Deprecated("`arg` is deprecated.")] = None) -> None: # The parameter `arg` is deprecated def my_function(name: str) -> Annotated[str, Deprecated("my_function is deprecated.")]: # Putting Deprecated in the return value type marks the method/function as deprecated. class MyClass: def __init__(self) -> Annotated[None, Deprecated("MyClass is deprecated.")]: # Marking __init__ as deprecated makes the class deprecated It is a no-op at runtime, and per PEP 593 it should be ignored by type checkers that don't support it. We also intend to include a higher-level decorator that will be turned into the lower-level annotations at type checking time. Here is an example: # API: def deprecated(message: str, stacklevel: int = 2) -> Callable[[_T], _T]: def decorator(wrapped): @functools.wraps(wrapped) def wrapper(*args, **kwargs): warnings.warn(message, DeprecationWarning, stacklevel=stacklevel) return wrapped(*args, **kwargs) return wrapper return decorator # Usage: @deprecated("my_func is deprecated") def my_func(name): print(f"Called my_func with {name}") At type checking time, it turns the function to def my_func(name) -> Annotated[?, Deprecated("my_func is deprecated")]. ? is either a concrete type if the type checker can infer its return type, or Any if not. At runtime, it raises a DeprecationWarning whenever my_func is called. **Feedback I'm looking for** ====================== Above isn't very detailed nor a finalized design. But I hope the idea is just clear enough to seek some initial feedback. The things I'm specifically looking for are: * Would the use of these APIs cause issues for other type checkers? Per my interpretation of PEP 593, it shouldn't. I tested with pytype, mypy, pyright, and pyre, one hiccup I found is pyre thinks annotating __init__ with Annotated[None, Deprecated("")] is an error (Incompatible constructor annotation [17]: __init__ is annotated as returning typing.Annotated[None], but it should return None.) * Is there interest from other type checkers to support such a deprecation library, so that static analysis tooling can provide better support detecting the use of deprecated APIs? Thanks, Yilei

5 6

Using Final to signify a singleton?
by Brett Cannon Sept. 29, 2021

Sept. 29, 2021

I was chatting with Guido about how there isn't an easy way to signal that something is a singleton. Concrete example: ```Python _NOTHING = object() class list(builtins.list): def __init__(self, iterable: Iterable | object = _NOTHING, /) -> None: if iterable is not _NOTHING: for item in iterable: ... # Fails to type check. ``` Even if I define a class just for this use-case, it still won't type check since the class that is instantiated once will still not be an iterable. ```Python class _NothingType: pass _NOTHING = _NothingType() ``` I'm not sure how best to handle this case. But while chatting with Guido he suggested one possibility might be to somehow use `Final` to signify that an object is acting as a singleton. Maybe something like: ```Python _NOTHING: Final[object] = object() ``` Then type checkers would know that `_NOTHING` is a singleton. Basically I want a way to write the following without a type failure: ```Python class list(builtins.list): def __init__(self, iterable: Iterable | _NOTHING = _NOTHING, /) -> None: if iterable is not _NOTHING: for item in iterable: ... ```

7 12

Next tensor typing meeting: Monday 13th
by Matthew Rahtz Sept. 20, 2021

Sept. 20, 2021

Hi all, Our next tensor typing meeting will be *Monday the 13th at 6pm London time / 10am San Francisco time *at http://meet.google.com/fft-dzjq-ksu. Agenda is yet to be confirmed. As always, notes and recordings from past meetings are available here <https://docs.google.com/document/d/1oaG0V2ZE5BRDjd9N-Tr1N0IKGwZQcraIlZ0N8ay…> . Thanks! Matthew

1 4

Literals in dynamic type checking
by Paul Bryan Sept. 18, 2021

Sept. 18, 2021

Background typing.Literal was defined with static type checking in mind. During static type checking, Literal requires the value being checked to be a literal value, matching one of the Literal value(s) specified. In a static type checking context, this behaviour is both intuitive and obvious. Problem During dynamic type checking, Literal can be specified in a type hint, but there is no obvious way to determine at runtime whether the value being checked is sourced from a Python literal or elsewhere. For example, it could have been loaded from JSON. Furthermore, it is not necessarily desirable to make such a determination at runtime. Pydantic currently validates a value against a Literal type hint without regard to whether it is a Python literal. It appears to simply check for type and value equality against the defined Literal values in the type hint. (This is originally how I interpreted Literal would behave when I first encountered it.) I believe this makes Pydantic’s use of Literal incompatible with static type checking tools like mypy. Ideas 1. Codify Pydantic’s current behavior without changing static type checking behavior (in PEP 586 or elsewhere) This would lead to many situations where code would pass type checking at runtime, but fail static type checking due to constraints on literal values. 2. Relax Literal’s “literalness” static type checking behavior I believe this would conflict with developers’ objectives of keeping the value “safe” by requiring it be literally supplied, not allowing it to be deserialized or built dynamically. (Discussed previously on this list.) 3. Just use Enum I would argue Enum is unnecessary verbose, requiring the definition of a class, separate members, subclassing and dunders (e.g. __str__) to handle string values. It requires unnecessary naming of values, and requires avoiding “invalid” names. (3.11’s StrEnum could mitigate some of this?) 4. Define a new “relaxed” Literal type hint Define a new type hint, paralleling Literal’s syntax, relaxing the requirement that the value be an actual literal. Candidate names like Figure[...], Value[...], enum[...]. It would likely not be included in stdlib, so would likely be implemented by dynamic type checking libraries. What are your thoughts? Thanks in advance for your consideration.

4 9

typing-extensions/backport: Dropping support for Python 2.7, 3.4, and 3.5
by Sebastian Rittau Sept. 9, 2021

Sept. 9, 2021

We plan to drop support for Python 2.7, 3.4, and 3.5 for typing-extensions. [1] These Python versions have reached end-of-life for at least a year and tooling starts to be a problem. The Python 2 version of the library already has some omissions compared to the Python 3 version. Older versions (up to 3.10.0.2) will remain available for these Python versions. We also plan to drop the typing backport for Python 2.7 and 3.4. [2] This is what later became the typing module in Python proper. The Python 2 module had its last commit in 2019 and the Python 3 module was made obsolete with the introduction of typing in Python 3.5. Of course, old packages will remain available, but we will make no new releases. If you have any concerns, please voice them either here or in the linked GitHub issues. - Sebastian [1] https://github.com/python/typing/issues/867 [2] https://github.com/python/typing/issues/877

1 0

Viability of letting TypedDict classes inherit from Generic without a PEP change
by isamodya＠gmail.com Sept. 9, 2021

Sept. 9, 2021

Hello typing-sig, I have started couple of threads before about adding `Generic` support for `TypedDict`. But this thread is specifically to get an idea about the viability to let `TypedDict` classes inherit from `Generic` **without a PEP change**. Specifically the impact on type checker implementations. The discussion was started in https://bugs.python.org/issue44863 (and associated PR: https://github.com/python/cpython/pull/27663). Copied (with minor edits) my reasoning from https://bugs.python.org/issue44863 :: TypedDict PEP-589 says: A TypedDict cannot inherit from both a TypedDict type and a non-TypedDict base class. So the current run time implementation has: `if type(base) is not _TypedDictMeta: raise TypeError(...)` This restricts the user from defining generic TypedDicts in the natural class based syntax: `class Pager(TypedDict, Generic[T]): ...` Although PEP 589 doesn't explicitly state generic support. I believe it is complete in covering all semantic details even with Generics. Even structural subtyping because it says: "Value types behave invariantly, since TypedDict objects are mutable." I have tried putting together a PEP from guidance of typing-sig <https://github.com/sransara/py-generic-typeddict/blob/master/pep-9999.rst>. There is not much new contributions by that draft, except for specifying the alternative syntax and being more explicit about Generics: 1. relaxing this line from PEP-589 and be explicit to include Generic: "A TypedDict cannot inherit from both a TypedDict type and a non-TypedDict base class." (IMO by thinking `Generic` as a mixin even this is not needed) 2. may be syntax for generic in the alternative syntax (side note: collecting typevars from the values is hard to implement because of forward refs) 3. Some explicit generic examples for good measure So I'm wondering if it would be possible to relax the constraint: TypedDict inheritance to include Generic. In my point of view `Generic` is more of a mixin, so it doesn't go against the PEP 589. Or is this change really big enough to warrant a new PEP or PEP update? My understanding was that during initial implementation this was not done for the sake of implementation simplicity (days before PEP-560). All that said, a new PEP would be a good way to notify the type checkers of this capability. Please let me know your thoughts.

2 1

Definition-site variance for TypeVar
by Sergei Lebedev Sept. 7, 2021

Sept. 7, 2021

Hi everyone, Type variables allow to specify their variance at construction time, i.e variance is currently a property of a type variable. This is problematic for cases when a type variable is used outside of a generic class. For example, T_co = TypeVar("T", covariant=True) def callback(value: T_co): ... or ListT = list[T_co] I am curious, if we could instead deprecate the variance parameters and make variance local to the generic class definition. Specifically, * all type variables are created invariant; * a type variable can be annotated as covariant and contravariant using unary + and - operators respectively; * these operators are only allowed when a type variable is referenced in the bases of a class definition. For example, here T = TypeVar("T") class Source(Generic[+T]): ... the class Source is covariant in T. Wdyt? Sergei

2 1

Re: Definition-site variance for TypeVar
by Gobot1234 Sept. 7, 2021

Sept. 7, 2021

There is a pep currently being written to support this, go to https://github.com/python/typing/issues/813 for the discussion about this.

1 0

How to extend Type or how to type a wrapper class
by Patrick Arminio Sept. 5, 2021

Sept. 5, 2021

Hi everyone! I'm trying to type a decorator that returns a Wrapper class of another class. The idea is that I have a wrapper class that only adds a couple of properties to the original class, something like this: ```python from typing import Type, TypeVar, Generic _T = TypeVar("_T") class Wrapper(Generic[_T]): wrap: Type[_T] enhanced: bool = True def __init__(self, cls: Type[_T]) -> None: self.wrap = cls def __call__(self, *args, **kwargs): ... def enhance(cls: Type[_T]) -> Type[_T]: return Wrapper(cls) # type: ignore class X: ... EnhanceX = enhance(X) reveal_type(EnhanceX) reveal_type(EnhanceX.enhanced) ``` The user using the class doesn't really need to know that it has been "enhanced", as it should work as it was before. My initial idea was to extend `Type` from typings, but that's not possible. What would you suggest to do here? Should I type all the methods on `Wrapper` to basically behave as if they were from `self.wrap`? not sure if that's actually possibile There's also a possibility where I'm doing something silly with what I'm trying to do, but it should make sense for my use case 😊

2 1