Mailman 3 March 2021 - Typing-sig

Typing persistent data structure
by Caleb Donovick March 18, 2021

March 18, 2021

I am trying to type check a persistent (immutable) data structure. However I am stumbling on restrictions on using covariant types as arguments. Is there a standard work around for this? Simplified Example: class Node(Generic[T_co]): def __init__(self, val: T_co, succ: Optional[Node[T_co]]) -> None: self.val: Final[T_co] = val self.succ: Final[Optional[Node[T_co]]] = succ class List(Sequence[T_co]): def __init__(self, *, _head: Optional[Node[T_co]] = None) -> None: self.head: Final[Optional[Node[T_co]]] = _head # The problem method def push_front(self, val: T_co) -> List[T_co]: new_node = Node(val, self.head) return List(_head=new_node) def __iter__(self) -> Iterator[T_co]: ptr = self.head while ptr is not None: yield ptr.val ptr = ptr.succ ...

2 1

Typing Summit 2021 Interest Form
by Shannon Zhu March 16, 2021

March 16, 2021

Hi everyone! Alfonso and I have been working on organizing a Typing Summit in partnership with PyCon, for developers and users of Python static type checkers. If you are interested in attending, please fill out this signup form<https://docs.google.com/forms/d/e/1FAIpQLSct42iXWscqznadBYSSsJUWm0wLd9IFKS0…>. Because the summit is co-located with PyCon, it will take place on the 12th or 13th of May. Our tentative schedule is Wednesday, May 12th from 11AM-3PM EST (8AM-12PM PST, 5PM-9PM CET) to accommodate as many time zones as possible. As in previous years, we hope to make the summit as discussion-oriented as possible. To facilitate this, we encourage presenters to prepare an agenda for their topic, including an introductory presentation and any materials that discussion participants should check in advance. Although different topics may require different discussion formats, the goal is to make sure that participants are up to date with the state of the topic and prepared to provide constructive ideas after the presentation. Finally, we are sending this form to understand what topics you want to see covered, whether you want or are willing to present the topic, or just want to participate in its discussion. No worries in case that multiple people want to present the same topic, or if you are interested in discussing a topic that nobody has proposed presenting: soon after we will share the form results so that we can discuss how to get the topics properly covered. Thanks! We are looking forward to seeing everyone at the summit! Alfonso & Shannon

2 2

Next tensor typing meeting
by Matthew Rahtz March 16, 2021

March 16, 2021

Hi everyone, Our next tensor typing meeting will be happening this coming *Monday the 15th of March*, at 6pm London time, 10am San Francisco time. As always, we'll be meeting at meet.google.com/fft-dzjq-ksu. You can take a look at what we've talked about in our past meetings here <https://docs.google.com/document/d/1oaG0V2ZE5BRDjd9N-Tr1N0IKGwZQcraIlZ0N8ay…> . The agenda this time is a short one: - Summary of where we're at with PEP 646 - What the next steps are once the PEP is done If anyone would like to present or talk about anything else, give me a shout. Hope to see you there! Matthew

4 9

Review of PEP 646 (Variadic Generics)
by Guido van Rossum March 15, 2021

March 15, 2021

I have read the proposed PEP about variadic generics (PEP 646) and I like it enough that I want to sponsor it and want to help getting it over the finish line (we have to get the Steering Council to understand enough of it that they'll delegate approval to me :-). For reference, here's the PR that proposes to add PEP 646: https://github.com/python/peps/pull/1740 And here's the original Google Doc: https://docs.google.com/document/d/1oXWyAtnv0-pbyJud8H5wkpIk8aajbkX-leJ8JXs… A good review starts by briefly summarizing the proposal being reviewed, so here's the proposal in my own words. **Motivation A:** We want to create generic types that take an arbitrary number of type parameters, like Tuple. For example, Tensors where each dimension is a "type". There is a demonstration of this without variadics, but it requires defining types `Tensor1[T1]`, `Tensor2[T1, T2]`, etc.: https://github.com/deepmind/tensor_annotations. We want just `Tensor[T1]`, `Tensor[T1, T2]`, etc., for any number of parameters. **Motivation B:** The type of functions like map() and zip() cannot be expressed using the existing type system. The simplest example would be the type of ``` def foo(*args): return args a = foo(42, "abc") # Should have type Tuple[int, str] ``` **Proposal:** Introduce a new kind of type variable that can be instantiated with an arbitrary number of types, some new syntax, and a new type operator: ``` Ts = TypeVarTuple("Ts") # NEW T = TypeVar("T") def f(*args: *Ts) -> Tuple[*Ts]: ... class C(Generic[*Ts]): ... Callable[[*Ts], T] Tuple[*Ts] Map[SomeType, Ts] # SomeType is a generic of one parameter ``` In most cases the form `*Ts` may be preceded and/or followed by any number of non-variadic types, e.g., `Tuple[int, int, *Ts, str]`. In cases where it's unambiguous, multiple variadic type variables are also allowed, e.g., `Tuple[*Ts1, *Ts2]`. For older Python versions, `Expand[Ts]` would mean the same as `*Ts`. So now let me go on with my (generally favorable) review. (I left many detailed editorial comments in the Google Doc -- I will not repeat those here.) I like the proposal a lot, and I am glad that we now have (apparently) a working prototype in Pyre. This has been on our wish list since at least 2016 -- much early discussion happened in https://github.com/python/typing/issues/193 and at various meetings at PyCon and at the Bay Area Typing Meetups (links in the PEP). The proposed syntax has cycled through endless variations, and I am fine with the current proposal, even though it is still slightly clunky. There's also https://github.com/python/typing/issues/513, which is specifically about array types. There are probably other motivating applications that the PEP doesn't mention, for example certain decorator types (I doubt that all of these are taken care by PEP 612, ParamSpec). I wonder why the proposal left out `Union[*Ts]`. This would seem useful, e.g. to type this function: ``` def f(*args): return random.choice(args) ``` which could be typed naturally as follows: ``` def f(*args: *Ts) -> Union[*Ts]: return random.choice(args) ``` I'm not sure that `Tensor[T1, T2, ...]` is the be-all and end-all of tensor types (e.g. where would you put the data type of numpy arrays?) but maybe that can be handled by just adding one non-variadic type variable (a complete example would be nice though). There are also proposals for integer generics, which deserve their own PEP (presumably aiming at Python 3.11). Eric Traut proposed an extension that would allow defining variadic subtypes of Sequence which behave similar to Tuple (where `Tuple[int, int]` is a subtype of `Tuple[int, ...]` which is a subtype of `Sequence[int]`), but I'm not sure we would need that a lot -- we could always add that later. The introduction of a prefix `*` operator requires new syntax in a few cases. While `Callable[[*Ts], T]` is already valid (the parser interprets this as sequence unpacking), `Tuple[*Ts]` is not, and neither is `def f(*a: *Ts)`. For `Tuple[*Ts]` we can piggy-back on PEP 637 (keyword indexing, which adds this as well), but for the `def` example we'll need to add something new specifically for this PEP. I think that's fine -- we can give it runtime semantics that turns `*Ts` into `(*Ts,)`, which is similar to the other places: at runtime it iterates over the argument, producing a tuple. In all cases we need to support `Expand[Ts]` as well for backwards compatibility with Python 3.9 and before. The `Map[]` operator is, as I said, fairly clunky. In the past various other syntaxes have been proposed. In particular, @sixolet p <https://github.com/python/typing/issues/513>roposed a syntax that would allow defining `zip()` as follows: ``` def zip(*args: Iterable[Ts]) -> Iterator[Tuple[Ts, ...]]: ... ``` Compare this to what it would look using the current proposal: ``` def zip(*args: *Map[Iterable, Ts]) -> Iterator[Ts]): ... # Note that Iterator[Ts] is the same as Iterator[Tuple[*Ts]] ``` Sixolet's syntax made the iteration over the elements of Ts implicit, which is slightly shorter, and doesn't require "higher-order type functions" (is there an official name for that?), but also slightly more cryptic, and created yet another use for the ellipsis: `Tuple[Ts, ...]` is not quite analogous to `Tuple[T, ...]`, since the latter is *homogeneous* while the former is still heterogeneous. The new notation uses an explicit `Map[]` operator, which is similar to the choice we made in PEP 612 for `Concatenate[]`. (Speaking of this choice, we could drop the `*` prefix and rely purely on `Expand[]`, but that feels unnecessarily verbose, and we'll get most of the needed syntax for free with PEP 637, assuming it's accepted.) All in all my recommendation for this PEP is: clean up the text based on the GDoc feedback, add `Union[*Ts]`, and submit to the Steering Council. -- --Guido van Rossum (python.org/~guido) *Pronouns: he/him **(why is my pronoun here?)* <http://feministing.com/2015/02/03/how-using-they-as-a-singular-pronoun-can-…>

11 80

Combining PEPs 637 & 655 to define inline TypedDicts
by Andrew Taumoefolau March 12, 2021

March 12, 2021

Hi there, It's fairly common within our code bases to define throwaway dicts for adding logging context or generating keyword arguments dynamically, e.g.: kwargs = {} if foo: kwargs["something"] = foo if bar: kwargs["another_thing"] = [1, 2, 3] cool_function(**kwargs) Defining TypedDict subclasses for these throwaway dicts can be tiresome, so these often get annotated with dict[str, Any], which opens a door for errors that a type checker would catch if we did define TypedDicts for them. I've been following the progress of PEPs 637 & 655 and had a thought this morning that they could be combined to generate a not-horrifically-ugly way to define TypedDicts inline. For the example above: kwargs: TypedDict[something=Required[str], another_thing=NotRequired[list[int]]] = {} if foo: ... Is it worth pursuing this thought further, or are there blockers on this that I'm oblivious to? Cheers, Andrew

3 2

Static typing for Ellipsis
by henryfs＠princeton.edu March 10, 2021

March 10, 2021

Currently, there's no PEP 484 way to type an Ellipsis, making it hard to add type checking to getitem/setitem. Type checkers (like MyPy, and it appears PyType) have supported "ellipsis" (as a string) as a stand-in for the missing type. This breaks linters like pyflakes, which expect "ellipsis" to be imported from somewhere even when it's a string, since it's not a builtin. (It MyPy's case, it also doesn't participate in narrowing, for some reason). It's also very difficult to discover. It seems the most user-friendly solution would be to add a special case for Ellipsis, just like there is one for None (and NotImplemented might be due such a special case, too, based on the original thread from last year which I hope is linked in here). MyPy clearly differentiates between "..." and "Ellipsis" now; tuple[int, Ellipsis] does not work as a stand-in for tuple[int, ...]. Like None, there is only one Ellipsis, and it does not have an accessible base type. If there's a problem with that solution, then adding "ellipsis" to typing would be a second possible solution. Then the name is correctly importable, and a bit more discoverable than a type-checker-only name. But IMO this should only be used if absolutely impossible to implement the first solution. See also the issue in pyflakes: https://github.com/PyCQA/pyflakes/issues/616 with a couple of examples.

4 3

Accessing non-required fields of a TypedDict
by Eric Traut March 10, 2021

March 10, 2021

A Pyright user just posted a feature request [here](https://github.com/microsoft/pyright/issues/1584). He's suggesting that Pyright (and type checkers in general) should flag as an error a subscripted access to a non-required field within a TypedDict. Here's an example (using the new PEP 655 notation for simplicity). ```python from typing import TypedDict class MyDict(TypedDict): fieldA: str fieldB: NotRequired[int] def func(x: MyDict): a = x['fieldA'] # OK b = x['fieldB'] # Should generate an error b = x.get('fieldB') # OK ``` I noticed that mypy does not flag x['fieldB'] as an error even though the field is potentially not present. I presume that code should always use the `get` method when attempting to access such fields. I'm curious why the TypedDict support in mypy doesn't emit an error in this case. Was that an oversight, or perhaps there was there a concern about generating false positives? My inclination is to always emit an error when code attempts to access a non-required TypedDict field using a subscript. Thoughts? -- Eric Traut Contributor to Pyright & Pylance Microsoft Corp.

4 4

Annotating exhaustiveness of if-elif and match
by Adrian Freund March 7, 2021

March 7, 2021

Hello, currently when people want to annotate that a if-elif check should be exhaustive and have a type-checker like mypy verify the exhaustiveness they have to resort to a clever hack that looks like this (This works in mypy. I haven't verified any other type-checkers): ```| from typing import NoReturn | |def assert_never(x: NoReturn) -> NoReturn: raise AssertionError(f"Invalid value: {x!r}") from typing import Union def type_checking_ok(foo: Union[str, int]) -> None: if isinstance(foo, str): print("str") elif isinstance(foo, int): print("int") else: assert_never(foo) def type_checking_ko(foo: Union[str, int]) -> None: if isinstance(foo, str): print("str") else: assert_never(foo) ``` This works by abusing the fact that mypy doesn't typecheck unreachable code and assert_never can't be called by a valid function call (*except for corner cases I will discuss later). Mypy also won't report it as unreachable if it is unreachable, as it returns `NoReturn`. If it can be reached mypy will complain about incompatible parameter types. This has a few problems: * It can be broken by `Any`. For example if `foo` is of type `Union[int, Any]` and you only check for `int` mypy won't show an error * According to PEP 484 `NoReturn` is only valid as a return type and should be considered an error if it appears in any other positions. * Some type-checkers might report the error, even if it is unreachable This is used in the wild for example by pytest. Due to python 3.10 introducing the match statement there will probably also be renewed interest in checking exhaustiveness. Therefor I would really like to see an official way to annotate this. There have already been discussions. There have already been multiple discussions of this topic on both the mypy github and the typing github: https://github.com/python/typing/issues/735 https://github.com/python/mypy/issues/5818 (https://github.com/python/mypy/issues/9748) Discussed solutions/improvements include: * Changing how `Any` and `NoReturn` interact https://github.com/python/mypy/issues/3194 * Changing PEP 484 to lift restrictions on `NoReturn` * Introducing `typing.Never` as an alias for `NoReturn` and not holding it to the same restrictions * Using a self-defined class `Impossible` as parameter type for `assert_never` and just not creating instances of it (Also has the Any problem) * Reporting reachable `assert False` as error (Might lead to a lot of false positives, where a `assert False` is unreachable but it can't be statically determined) My suggestion would be |adding |`assert_exhaustive(x: Any)`| to |typing|. The implementation could raise a fitting exception (Just |assert False| would of course also work, but I would argue that it's helpful to also give more details if it fails at runtime. Not only if it fails during type-checking). Type-checkers can then just be hardcoded to handle `assert_exhaustive()`. They could also make sure that `assert_exhaustive()` is only used within `else` blocks (and maybe `case _` blocks in the future). PS: Starting in April I will be writing my bachelors thesis on the topic of "Exhaustiveness check for Structural Pattern Matching in Python 3.10". My work will most likely be based on mypy and I'm planing to contribute the code back to upstream. Having an "official" way to annotate exhaustiveness would be really useful for me. -- Adrian Freund ||

2 2

Alternative notation for Callable
by mark00bell＠gmail.com March 6, 2021

March 6, 2021

PEP 604 introduced a new notation for specifying Unions, with `X | Y` being an alias for `typing.Union[X, Y]`. While thinking about other notations that could be useful, I would like to suggest also having `[ArgType1, ArgType2, ArgType3] -> ReturnType` as an alternative for `typing.Callable[[ArgType1, ArgType2, ArgType3], ReturnType]` This would then mean that, for example, we could annotate the `map` function as: `def map(func: [X] -> Y, items: Iterable[X]) -> Iterable[Y]:` Which would make this very similar to the annotation used to define a function that can be passed into `map`: ` def f(x: X) -> Y:` What do people think of this proposal? (I originally submitted this https://discuss.python.org/t/additional-type-annotation-for-callable/6800 here but was told that this mailing list may be more appropriate, please let me know if there is somewhere more appropriate to ask this)

5 4

TypeForm: Type Hint for Typing Special Forms and Regular Types
by David Foster March 4, 2021

March 4, 2021

I have drafted an initial PEP for TypeForm, a way to spell the type of typing special forms (like Union[int, str], Literal['foo'], etc). Please see the following commentable document, or the copy at the bottom of this email: https://docs.google.com/document/d/18UF8V00EVU1-h-BtiVFhXoJkvfL4rHp4ORaenMQ… Please leave your comments either on the document itself or by responses to this email on typing-sig. I will integrate feedback periodically. For further background on why this feature is being introduced and prior discussions, please see: (1) the originating thread on typing-sig at: https://mail.python.org/archives/list/typing-sig@python.org/thread/I5ZOQICT… (2) the discussion about TypeForm on the mypy issue tracker at: https://github.com/python/mypy/issues/9773 -- David Foster | Seattle, WA, USA Contributor to TypedDict support for mypy >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> PEP: 9999 Title: TypeForm: Type Hints for Typing Special Forms and Regular Types Author: David Foster <david(a)dafoster.net> Sponsor: TODO Discussions-To: typing-sig(a)python.org Status: Draft Type: Standards Track Content-Type: text/x-rst Requires: 647 (TypeGuard) Created: 21-Dec-2020 Python-Version: 3.10 Post-History: 24-Jan-2021 Abstract ======== PEP 484 [^type-c] defines the type `Type[C]` where `C` is a class, to refer to a class object that is a subtype of `C`. It explicitly does not allow `Type[C]` to refer to typing special forms such as the runtime object `Optional[str]` even if `C` is an unbounded `TypeVar`. This PEP proposes a new type `TypeForm` that allows referring to both any class object and *also* to any runtime object that is a typing special form, such as `Optional[str]`, `Union[int, str]`, or `MyTypedDict`. [^type-c]: https://www.python.org/dev/peps/pep-0484/#the-type-of-class-objects Motivation ========== The introduction of `TypeForm` allows new kinds of metaprogramming functions that operate on typing special forms to be type-annotated. For example, here is a function that checks whether a value is assignable to a variable of a particular type, and if so returns the original value: ``` T = TypeVar('T') def trycast(form: TypeForm[T], value: object) -> Optional[T]: ... ``` And here is another function that checks whether a value is assignable to a variable of a particular type, and if so returns `True`: ``` def isassignable(value: object, form: TypeForm) -> bool: ... ``` With the introduction of `TypeGuard` in PEP 647[^TypeGuardPep] the above function can be enhanced to return a `TypeGuard` instead of a regular `bool`: [^TypeGuardPep]: https://www.python.org/dev/peps/pep-0647/ ``` def isassignable(value: object, form: TypeForm[T]) -> TypeGuard[T]: ... ``` Without `TypeForm` the next-best type that could be given to the `form` parameter in the above examples would be `object` which would improperly allow values like `1` to be passed in. More importantly, there would be no way to express the relationship between the parameter type of `form` and the function's return type. NB: The preceding example functions implement the kinds of enhanced `isinstance` checks that were omitted in PEP 589[^typeddict-no-isinstance] which are very useful for, among other things, [checking whether a value decoded from JSON conforms to a particular structure] of nested `TypedDict`s, `List`s, `Optional`s, `Literal`s, and other types. [^typeddict-no-isinstance]: https://www.python.org/dev/peps/pep-0589/#using-typeddict-types [checking whether a value decoded from JSON conforms to a particular structure]: https://mail.python.org/archives/list/typing-sig@python.org/thread/I5ZOQICT… Specification ============= A type-form type represents a `type` object or a special typing form such as `Optional[str]`, `Union[int, str]`, or `MyTypedDict`. A type-form type can be written as either `TypeForm[T]` where `T` is a type variable or as `TypeForm` with no argument. The `T` in `TypeForm[T]` is always an invariant type variable with no bound: * Attempting to use a type variable `T` declared with a `bound=...` or marked with `covariant=True` or `contravariant=True` in a `TypeForm[T]` should be rejected by typecheckers. * Attempting to use a literal type-form `*form*` as an argument to `TypeForm[*form*]`, such as `TypeForm[int]`, should be rejected by typecheckers. (See §"TypeForm[*form*] or Literal[*form*]" in Rejected Ideas for rationale.) The syntax `TypeForm` alone, without a type argument, is equivalent to `TypeForm[_T]` where `_T` is a freshly created type variable. ``` T = TypeVar('T') def trycast(form: TypeForm[T], value: object) -> Optional[T]: ... def isassignable(value: object, form: TypeForm) -> bool: ... def is_type(form: TypeForm) -> bool: ... ``` Using TypeForm Types -------------------- Type-form types may be used as function parameter types, return types, and variable types: ``` def is_type(form: TypeForm) -> bool: ... # parameter type ``` ``` S = TypeVar('S') T = TypeVar('T') U = TypeVar('U') def meet_types(s: TypeForm[S], t: TypeForm[T]) \ -> Union[TypeForm[S], TypeForm[T], TypeForm[U]]: ... # return types ``` ``` NULL_TYPE: TypeForm # variable type NULL_TYPE = type(None) ``` ``` NULL_TYPE: TypeForm = type(None) # variable type ``` Note however that a typechecker won't automatically infer a TypeForm type for an unannotated variable assignment that contains a special typing form on the right-hand-side because PEP 484 [^type-alias-syntax] reserves that syntax for defining type aliases: [^type-alias-syntax]: https://www.python.org/dev/peps/pep-0484/#type-aliases ``` NULL_TYPE = type(None) # OOPS; treated as a type alias! ``` If you want a typechecker to infer a TypeForm variable type for a bare assignment, use the walrus operator instead of the assignment operator: ``` NULL_TYPE := type(None) # infers NULL_TYPE as having type TypeForm ``` Or explicitly declare the assignment-target as having `TypeForm` type: ``` NULL_TYPE: TypeForm = type(None) ``` ``` NULL_TYPE = type(None) # type: TypeForm # the type comment is significant ``` ``` NULL_TYPE: TypeForm NULL_TYPE = type(None) ``` Values of type TypeForm ----------------------- A particular literal value is said to *inhabit* a type if it is described by that type and can be assigned to a variable of that type. The type `TypeForm` is inhabited by exactly those runtime objects that are valid on the right-hand-side of a variable declaration, ``` value: *form* ``` the right-hand-side of a parameter declaration, ``` def some_func(value: *form*): ``` *and* as the return type of a function: ``` def some_func() -> *form*: ``` Any runtime object that is not valid in one of the above locations is not an inhabitant of `TypeForm`. For example the special forms `Final`, `Final[int]`, `NoReturn`, and `ClassVar[int]` are not inhabitants. Incomplete forms like a bare `Optional` or `Union` are also not inhabitants. Example of inhabitants include: * type objects like `int`, `str`, `object`, and `FooClass` * generic collections like `List`, `List[int]`, `Dict`, or `Dict[K, V]` * callables like `Callable`, `Callable[[Arg1Type, Arg2Type], ReturnType]`, `Callable[..., ReturnType]` * union forms like `Optional[str]` or `Union[int, str]` * literal forms like `Literal['r', 'rb', 'w', 'wb']` * type variables like `T` or `AnyStr` * annotated types like `Annotated[int, ValueRange(-10, 5)]` * type aliases like `Vector` (where `Vector = list[float]`) * the `Any` form * the `Type` and `Type[C]` forms * the `TypeForm` and `TypeForm[T]` forms A few peculiar cases permitted by the above include: ``` STR_FORM: TypeForm = str STR_OR_SUBCLASS_FORM: TypeForm = Type[str] SOME_FORM: TypeForm = TypeForm ``` Forward References '''''''''''''''''' Runtime objects for forms which contain forward references such as `Union['Triangle', 'Shape']` are normalized at runtime to `Union[ForwardRef('Triangle'), ForwardRef('Shape')]`. The latter are inhabitants of `TypeForm`. Additionally the "top-level" form for a particular variable type can itself be a forward reference such as in: ``` class Node: value: object next: 'Node' # 'Node' is normalized to ForwardRef('Node') at runtime ``` Code that manipulates TypeForm values at runtime should be prepared to deal with ForwardRef(...) subcomponents. Type Consistency ---------------- Informally speaking, *type consistency* is a generalization of the is-subtype-of relation to support the `Any` type. It is defined more formally in PEP 483 [^type-consistency]. This section introduces the new rules needed to support type consistency for TypeForm types: [^type-consistency]: https://www.python.org/dev/peps/pep-0483/#summary-of-gradual-typing * `Type[C]` is consistent with `TypeForm`. `TypeForm` is consistent with `object`. * `TypeForm[S]` is consistent with `TypeForm[T]` iff `S` and `T` are the same type variable. * `Any` is consistent with `TypeForm`. `TypeForm` is consistent with `Any`. Overloading ----------- `TypeForm` can be used in overloads. For example: ``` T = TypeVar('T') F = TypeVar('F') @overload def trycast(form: TypeForm[T], value: object) -> Optional[T]: ... @overload def trycast(form: TypeForm[T], value: object, failure: F) -> Union[T, F]: ... ``` Interactions with Type[C] ------------------------- A `TypeForm` and a `Type` cannot simultaneously constrain the same type variable within a generic function definition: ``` def bad_func(form: TypeForm[T], tp: Type[T]): ... # invalid ``` A group of type variables where some variables are constrained by `TypeForm`s, some are constrained by `Type`s, and others are unconstrained may appear together as arguments to the same type constructor (i.e. `Union[...]`, `Dict[K, V]`, etc): ``` F = TypeVar('F') C = TypeVar('C') V = TypeVar('V') def pick_random(form: TypeForm[F], tp: Type[C], value: V) -> Union[F, C, V]: ... ``` Interactions with cast ---------------------- It is possible to cast a value to a `TypeForm` or `TypeForm[T]` type: ``` OPTIONAL_STR_OBJECT: object = Optional[str] OPTIONAL_STR = cast(TypeForm, OPTIONAL_STR_OBJECT) ``` Type Inference -------------- A runtime object corresponding to a special form should be inferred as having type `TypeForm` unless it can instead be inferred to have type `Type[C]` for some `C`: ``` T = TypeVar('T') def identity(value: T) -> T: return value A_TYPE = identity(str) # inferred type is: Type[str] A_FORM = identity(Optional[str]) # inferred type is: TypeForm ``` Backwards Compatibility ======================= Previously the type `object` would be inferred for runtime objects corresponding to a special form like `Optional[str]` rather than `TypeForm`. But since `TypeForm` is consistent with `object` no unexpected typechecking failures will be introduced by this change. Ongoing Maintenance =================== As new kinds of typing special forms are introduced by upcoming PEPs (usually to the `typing` module), it will be necessary for typecheckers to define whether or not the new forms should be considered inhabitants of `TypeForm` or not, based on the general rules in §"Values of type TypeForm" above. Therefore it is recommended that any new PEP introducing a new typing special form should define whether it inhabits `TypeForm` or not. Reference Implementation ======================== The following will be true when [mypy#9773](https://github.com/python/mypy/issues/9773) is implemented: The mypy type checker supports `TypeForm` types. A reference implementation of the runtime component is provided in the `typing_extensions` module. In addition an implementation of the `trycast` and `isassignable` functions mentioned in various examples above is being implemented in the [trycast PyPI module](https://github.com/davidfstr/trycast). Rejected Ideas ============== TypeForm[*form*] or Literal[*form*] ----------------------------------- This PEP only defines syntax for a bare `TypeForm` and a `TypeForm[T]` parameterized by a type variable. In particular it does not define syntax like that allows referring to a specific known type-form value via a syntax like `TypeForm[*form*]`: ``` NULL_TYPE := type(None) # has type TypeForm[_T] rather than TypeForm[type(None)] UNION_STR_TYPE := Union[Str] # has type TypeForm[_T] rather than TypeForm[Union[str]] ``` In addition similar syntax like `Literal[*form*]` also does not work. Neither of those syntaxes seem to be especially useful; type forms are not typically used as sentinel values. It is possible that a future PEP may revisit such syntaxes. Open Issues =========== [Any points that are still being decided/discussed.] References ========== [A collection of URLs used as references through the PEP.] 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: <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<

5 27