Prisma-style ORMs

Prisma, a popular ORM for TypeScript, allows writing queries like (adapted from this example):

const user = await prisma.user.findMany({
  select: {
    name: true,
    email: true,
    posts: true,
  },
});

for which the inferred type will be something like:

{
    email: string;
    name: string | null;
    posts: {
        id: number;
        title: string;
        content: string | null;
        authorId: number | null;
    }[];
}[]

Here, the output type is a combination of both existing information about the type of prisma.user and the type of the argument to findMany. It returns an array of objects containing the properties of user that were requested; one of the requested elements, posts, is a “relation” referencing another model; it has all of its properties fetched but not its relations.

We would like to be able to do something similar in Python, perhaps with a schema defined like:

class Comment:
    id: Property[int]
    name: Property[str]
    poster: Link[User]


class Post:
    id: Property[int]

    title: Property[str]
    content: Property[str]

    comments: MultiLink[Comment]
    author: Link[User]


class User:
    id: Property[int]

    name: Property[str]
    email: Property[str]
    posts: Link[Post]

(In Prisma, a code generator generates type definitions based on a prisma schema in its own custom format; you could imagine something similar here, or that the definitions were hand-written)

and a call like:

db.select(
    User,
    name=True,
    email=True,
    posts=True,
)

which would have return type list[<User>] where:

class <User>:
    name: str
    email: str
    posts: list[<Post>]

class <Post>:
    id: int
    title: str
    content: str

(Example code for implementing this below.)

Automatically deriving FastAPI CRUD models

In the FastAPI tutorial, they show how to build CRUD endpoints for a simple Hero type. At its heart is a series of class definitions used both to define the database interface and to perform validation/filtering of the data in the endpoint:

class HeroBase(SQLModel):
    name: str = Field(index=True)
    age: int | None = Field(default=None, index=True)


class Hero(HeroBase, table=True):
    id: int | None = Field(default=None, primary_key=True)
    secret_name: str


class HeroPublic(HeroBase):
    id: int


class HeroCreate(HeroBase):
    secret_name: str


class HeroUpdate(HeroBase):
    name: str | None = None
    age: int | None = None
    secret_name: str | None = None

The HeroPublic type is used as the return type of the read endpoint (and is validated while being output, including having extra fields stripped), while HeroCreate and HeroUpdate serve as input types (automatically converted from JSON and validated based on the types, using Pydantic).

Despite the multiple types and duplication here, mechanical rules could be written for deriving these types:

• Public should include all non-“hidden” fields, and the primary key should be made non-optional
• Create should include all fields except the primary key
• Update should include all fields except the primary key, but they should all be made optional and given a default value

With the definition of appropriate helpers, this proposal would allow writing:

class Hero(NewSQLModel, table=True):
    id: int | None = Field(default=None, primary_key=True)

    name: str = Field(index=True)
    age: int | None = Field(default=None, index=True)

    secret_name: str = Field(hidden=True)

type HeroPublic = Public[Hero]
type HeroCreate = Create[Hero]
type HeroUpdate = Update[Hero]

Those types, evaluated, would look something like:

class HeroPublic:
    id: int
    name: str
    age: int | None


class HeroCreate:
    name: str
    age: int | None = None
    secret_name: str


class HeroUpdate:
    name: str | None = None
    age: int | None = None
    secret_name: str | None = None

While the implementation of Public, Create, and Update are certainly more complex than duplicating code would be, they perform quite mechanical operations and could be included in the framework library.

A notable feature of this use case is that it depends on performing runtime evaluation of the type annotations. FastAPI uses the Pydantic models to validate and convert to/from JSON for both input and output from endpoints.

Currently it is possible to do the runtime half of this: we could write functions that generate Pydantic models at runtime based on whatever rules we wished. But this is unsatisfying, because we would not be able to properly statically typecheck the functions.

(Example code for implementing this below.)

dataclasses-style method generation

We would additionally like to be able to generate method signatures based on the attributes of an object. The most well-known example of this is probably generating __init__ methods for dataclasses, which we present a simplified example of. (In our test suites, this is merged with the FastAPI-style example above, but it need not be).

This kind of pattern is widespread enough that PEP 681 was created to represent a lowest-common denominator subset of what existing libraries do.

Making it possible for libraries to implement more of these patterns directly in the type system will give better typing without needing further special casing, typechecker plugins, hardcoded support, etc.

(Example code for implementing this below.)

More powerful decorator typing

The typing of decorator functions has long been a pain point in Python typing. The situation was substantially improved by the introduction of ParamSpec in PEP 612, but a number of patterns remain unsupported:

• Adding/removing/modifying a keyword parameter
• Adding/removing/modifying a variable number of parameters. (Though TypeVarTuple is close to being able to support adding and removing, if multiple unpackings were to be allowed, and Pyre implemented a Map operator that allowed modifying multiple.)

This proposal will cover those cases.

Unpack of typevars for **kwargs

A minor proposal that can probably be split off into a typing proposal without a PEP:

Supporting Unpack of typevars for **kwargs:

def f[K: BaseTypedDict](**kwargs: Unpack[K]) -> K:
    return kwargs

Here BaseTypedDict is defined as:

class BaseTypedDict(typing.TypedDict):
    pass

But any TypedDict would be allowed there.

Then, if we had a call like:

x: int
y: list[str]
f(x=x, y=y)

the type inferred for K would be something like:

TypedDict({'x': int, 'y': list[str]})

This is basically a combination of “PEP 692 – Using TypedDict for more precise **kwargs typing” and the behavior of Unpack for *args from “PEP 646 – Variadic Generics”.

When inferring types here, the type checker should infer literal types when possible. This means inferring literal types for arguments that do not appear in the bound, as well as for arguments that do appear in the bound as read-only (TODO: Or maybe we should make whether to do it for extra arguments configurable in the TypedDict serving as the bound somehow? If readonly had been added as a parameter to TypedDict we would use that.)

For each non-required item in the bound that does not have a matching argument provided, then if the item is read-only, it will have its type inferred as Never, to indicate that it was not provided. (This can only be done for read-only items, since non read-only items are invariant.)

This is potentially moderately useful on its own but is being done to support processing **kwargs with type level computation.

—

Extended Callables, take 2

We introduce a new extended callable proposal for expressing arbitrarily complex callable types. The goal here is not really to produce a new syntax to write in annotations (it seems less pleasant to write than callback protocols are), but to provide a way of constructing the types that is amenable to creating and introspecting callable types using the other features of this PEP.

We introduce a Param type that contains all the information about a function param:

class Param[N: str | None, T, Q: ParamQuals = typing.Never]:
    pass

ParamQuals = typing.Literal["*", "**", "default", "keyword"]

type PosParam[N: str | None, T] = Param[N, T, Literal["positional"]]
type PosDefaultParam[N: str | None, T] = Param[N, T, Literal["positional", "default"]]
type DefaultParam[N: str, T] = Param[N, T, Literal["default"]]
type NamedParam[N: str, T] = Param[N, T, Literal["keyword"]]
type NamedDefaultParam[N: str, T] = Param[N, T, Literal["keyword", "default"]]
type ArgsParam[T] = Param[Literal[None], T, Literal["*"]]
type KwargsParam[T] = Param[Literal[None], T, Literal["**"]]

And then, we can represent the type of a function like:

def func(
    a: int,
    /,
    b: int,
    c: int = 0,
    *args: int,
    d: int,
    e: int = 0,
    **kwargs: int
) -> int:
    ...

as (we are omitting the Literal in places):

Callable[
    [
        Param["a", int, "positional"],
        Param["b", int],
        Param["c", int, "default"],
        Param[None, int, "*"],
        Param["d", int, "keyword"],
        Param["e", int, Literal["default", "keyword"]],
        Param[None, int, "**"],
    ],
    int,
]

or, using the type abbreviations we provide:

Callable[
    [
        PosParam["a", int],
        Param["b", int],
        DefaultParam["c", int],
        ArgsParam[int],
        NamedParam["d", int],
        NamedDefaultParam["e", int],
        KwargsParam[int],
    ],
    int,
]

(Rationale discussed below.)

TODO: Should the extended argument list be wrapped in a typing.Parameters[*Params] type (that will also kind of serve as a bound for ParamSpec)?

Grammar specification of the extensions to the type language

Note first that no changes to the Python grammar are being proposed, only to the grammar of what Python expressions are considered as valid types.

(It’s also slightly imprecise to call this a grammar: <bool-operator> refers to any of the names defined in the Boolean Operators section, which might be imported qualified or with some other name)

<type> = ...
     # Type booleans are all valid types too
     | <type-bool>

     # Conditional types
     | <type> if <type-bool> else <type>

     # Types with variadic arguments can have
     # *[... for t in ...] arguments
     | <ident>[<variadic-type-arg> +]

     # Type member access (associated type access?)
     | <type>.<name>

     | GenericCallable[<type>, lambda <args>: <type>]

# Type conditional checks are boolean compositions of
# boolean type operators
<type-bool> =
      <bool-operator>[<type> +]
    | not <type-bool>
    | <type-bool> and <type-bool>
    | <type-bool> or <type-bool>
    | any(<type-bool-for>)
    | all(<type-bool-for>)

<variadic-type-arg> =
      <type> ,
    | * [ <type-for-iter> ] ,


<type-for> = <type> <type-for-iter>+ <type-for-if>*
<type-for-iter> =
      # Iterate over a tuple type
      for <var> in Iter[<type>]
<type-for-if> =
      if <type-bool>

(<type-bool-for> is identical to <type-for> except that the result type is a <type-bool> instead of a <type>.)

There are three and a half core syntactic features introduced: type booleans, conditional types, unpacked comprehension types, and type member access.

“Generic callables” are also technically a syntactic feature, but are discussed as an operator.

Type operators

In some sections below we write things like Literal[int] to mean “a literal that is of type int”. I don’t think I’m really proposing to add that as a notion, but we could.

class InitField[KwargDict: BaseTypedDict]:
    def __init__(self, **kwargs: typing.Unpack[KwargDict]) -> None:
        ...

    def _get_kwargs(self) -> KwargDict:
        ...

class A:
    foo: int = InitField(default=0, kw_only=True)

Lifting over Unions

Many of the builtin operations are “lifted” over Union.

For example:

Concat[Literal['a'] | Literal['b'], Literal['c'] | Literal['d']] = (
    Literal['ac'] | Literal['ad'] | Literal['bc'] | Literal['bd']
)

When an operation is lifted over union types, we take the cross product of the union elements for each argument position, evaluate the operator for each tuple in the cross product, and then union all of the results together. In Python, the logic looks like:

args_union_els = [get_union_elems(arg) for arg in args]
results = [
    eval_operator(*xs)
    for xs in itertools.product(*args_union_els)
]
if results:
    return Union[*results]
else:
    return Never

Runtime evaluation support

An important goal is supporting runtime evaluation of these computed types. We do not propose to add an official evaluator to the standard library, but intend to release a third-party evaluator library.

While most of the extensions to the type system are “inert” type operator applications, the syntax also includes list iteration, conditionals, and attribute access, which will be automatically evaluated when the __annotate__ method of a class, alias, or function is called.

In order to allow an evaluator library to trigger type evaluation in those cases, we add a new hook to typing:

• special_form_evaluator: This is a ContextVar that holds a callable that will be invoked with a typing._GenericAlias argument when __bool__ is called on a Boolean Operator or __iter__ is called on typing.Iter. The returned value will then have bool or iter called upon it before being returned.

  If set to None (the default), the boolean operators will return False while Iter will evaluate to iter(()).

There has been some discussion of adding a Format.AST mode for fetching annotations (see this PEP draft). That would combine extremely well with this proposal, as it would make it easy to still fetch fully unevaluated annotations.

Prisma-style ORMs

First, to support the annotations we saw above, we have a collection of dummy classes with generic types.

class Pointer[T]:
    pass

class Property[T](Pointer[T]):
    pass

class Link[T](Pointer[T]):
    pass

class SingleLink[T](Link[T]):
    pass

class MultiLink[T](Link[T]):
    pass

The select method is where we start seeing new things.

The **kwargs: Unpack[K] is part of this proposal, and allows inferring a TypedDict from keyword args.

Attrs[K] extracts Member types corresponding to every type-annotated attribute of K, while calling NewProtocol with Member arguments constructs a new structural type.

c.name fetches the name of the Member bound to the variable c as a literal type–all of these mechanisms lean very heavily on literal types. GetMemberType gets the type of an attribute from a class.

def select[ModelT, K: typing.BaseTypedDict](
    typ: type[ModelT],
    /,
    **kwargs: Unpack[K],
) -> list[
    typing.NewProtocol[
        *[
            typing.Member[
                c.name,
                ConvertField[typing.GetMemberType[ModelT, c.name]],
            ]
            for c in typing.Iter[typing.Attrs[K]]
        ]
    ]
]:
    raise NotImplementedError

ConvertField is our first type helper, and it is a conditional type alias, which decides between two types based on a (limited) subtype-ish check.

In ConvertField, we wish to drop the Property or Link annotation and produce the underlying type, as well as, for links, producing a new target type containing only properties and wrapping MultiLink in a list.

type ConvertField[T] = (
    AdjustLink[PropsOnly[PointerArg[T]], T]
    if typing.IsAssignable[T, Link]
    else PointerArg[T]
)

PointerArg gets the type argument to Pointer or a subclass.

GetArg[T, Base, I] is one of the core primitives; it fetches the index I type argument to Base from a type T, if T inherits from Base.

(The subtleties of this will be discussed later; in this case, it just grabs the argument to a Pointer).

type PointerArg[T] = typing.GetArg[T, Pointer, Literal[0]]

AdjustLink sticks a list around MultiLink, using features we’ve discussed already.

type AdjustLink[Tgt, LinkTy] = (
    list[Tgt] if typing.IsAssignable[LinkTy, MultiLink] else Tgt
)

And the final helper, PropsOnly[T], generates a new type that contains all the Property attributes of T.

type PropsOnly[T] = typing.NewProtocol[
    *[
        typing.Member[p.name, PointerArg[p.type]]
        for p in typing.Iter[typing.Attrs[T]]
        if typing.IsAssignable[p.type, Property]
    ]
]

The full test is in our test suite.

Automatically deriving FastAPI CRUD models

We have a more fully-worked example in our test suite, but here is a possible implementation of just Public

# Extract the default type from an Init field.
# If it is a Field, then we try pulling out the "default" field,
# otherwise we return the type itself.
type GetDefault[Init] = (
    GetFieldItem[Init, Literal["default"]]
    if typing.IsAssignable[Init, Field]
    else Init
)

# Create takes everything but the primary key and preserves defaults
type Create[T] = typing.NewProtocol[
    *[
        typing.Member[
            p.name,
            p.type,
            p.quals,
            GetDefault[p.init],
        ]
        for p in typing.Iter[typing.Attrs[T]]
        if not typing.IsAssignable[
            Literal[True],
            GetFieldItem[p.init, Literal["primary_key"]],
        ]
    ]
]

The Create type alias creates a new type (via NewProtocol) by iterating over the attributes of the original type. It has access to names, types, qualifiers, and the literal types of initializers (in part through new facilities to handle the extremely common = Field(...)-like pattern used here).

Here, we filter out attributes that have primary_key=True in their Field as well as extracting default arguments (which may be either from a default argument to a field or specified directly as an initializer).

dataclasses-style method generation

# Generate the Member field for __init__ for a class
type InitFnType[T] = typing.Member[
    Literal["__init__"],
    Callable[
        [
            typing.Param[Literal["self"], Self],
            *[
                typing.Param[
                    p.name,
                    p.type,
                    # All arguments are keyword-only
                    # It takes a default if a default is specified in the class
                    Literal["keyword"]
                    if typing.IsAssignable[
                        GetDefault[p.init],
                        Never,
                    ]
                    else Literal["keyword", "default"],
                ]
                for p in typing.Iter[typing.Attrs[T]]
            ],
        ],
        None,
    ],
    Literal["ClassVar"],
]
type AddInit[T] = typing.NewProtocol[
    InitFnType[T],
    *[x for x in typing.Iter[typing.Members[T]]],
]

Extended Callables

We need extended callable support, in order to inspect and produce callables via type-level computation. mypy supports extended callables but they are deprecated in favor of callback protocols.

Unfortunately callback protocols don’t work well for type level computation. (They probably could be made to work, but it would require a separate facility for creating and introspecting methods, which wouldn’t be any simpler.)

I am proposing a fully new extended callable syntax because:

1. The mypy_extensions functions are full no-ops, and we need real runtime objects
2. They use parentheses and not brackets, which really goes against the philosophy here.
3. We can make an API that more nicely matches what we are going to do for inspecting members (We could introduce extended callables that closely mimic the mypy_extensions version though, if something new is a non starter)

TODO: Currently I made the qualifiers be short strings, for code brevity when using them, but an alternate approach would be to mirror inspect.Signature more directly, and have an enum with names like ParamKind.POSITIONAL_OR_KEYWORD.

Generic Callable

Consider a method with the following signature:

def process[T](self, x: T) -> T if IsAssignable[T, list] else list[T]:
    ...

The type of the method is generic, and the generic is bound at the method, not the class. We need a way to represent such a generic function as a programmer might write it for a NewProtocol.

One option that is somewhat appealing but doesn’t work would be to use unbound type variables and let them be generalized:

type Foo = NewProtocol[
    Member[
        Literal["process"],
        Callable[[T], set[T] if IsAssignable[T, int] else T]
    ]
]

The problem is that this is basically incompatible with runtime evaluation support, since evaluating the alias Foo will need to evaluate the IsAssignable, and so we will lose one side of the conditional at least. Similar problems will happen when evaluating Members on a class with generic functions. By wrapping the body in a lambda, we can delay evaluation in both of these cases. (The Members case of delaying evaluation works quite nicely for functions with explicit generic annotations. For old-style generics, we’ll probably have to try to evaluate it and then raise an error when we encounter a variable.)

The reason we suggest restricting the use of GenericCallable to the type argument of Member is because impredicative polymorphism (where you can instantiate type variables with other generic types) and rank-N types (where generics can be bound in nested positions deep inside function types) are cans of worms when combined with type inference [4]. While it would be nice to support, we don’t want to open that can of worms now.

The unbound type variable tuple is so that bounds and defaults and TypeVarTuple-ness can be specified, though maybe we want to come up with a new approach.

Dictionary comprehension based syntax for creating typed dicts and protocols

This is in some ways an extension of the PEP 764 (still draft) proposal for inline typed dictionaries.

Combined with the above proposal, using it for NewProtocol might look (using something from the query builder example) something like:

type PropsOnly[T] = typing.NewProtocol[
    {
        p.name: PointerArg[p.type]
        for p in typing.Iter[typing.Attrs[T]]
        if typing.IsAssignable[p.type, Property]
    }
]

Then we would probably also want to allow specifying a Member (but reordered so that Name is last and has a default), for if we want to specify qualifiers and/or an initializer type.

We could also potentially allow qualifiers to be written in the type, though it is a little odd, since that is an annotation expression, not a type expression, and you probably wouldn’t be allowed to have an annotation expression in an arm of a conditional type?

The main downside of this proposal is just complexity: it requires introducing another kind of weird type form.

We’d also need to figure out the exact interaction between typeddicts and new protocols. Would the dictionary syntax always produce a typed dict, and then NewProtocol converts it to a protocol, or would NewProtocol[<dict type expr>] be a special form? Would we try to allow ClassVar and Final?

type PropsOnly[T] = typing.NewProtocol[
    {
        k: PointerArg[ty]
        for k, ty in typing.IterItems[typing.Attrs[T]]
        if typing.IsAssignable[ty, Property]
    }
]

Call type operators using parens

If people are having a bad time in Bracket City, we could also consider making the built-in type operators use parens instead of brackets.

Obviously this has some consistency issues but also maybe signals a difference? Combined with dictionary-comprehensions and dot notation (but not dictionary destructuring), it could look like:

type PropsOnly[T] = typing.NewProtocol(
    {
        p.name: PointerArg[p.type]
        for p in typing.Iter(typing.Attrs(T))
        if typing.IsAssignable(p.type, Property)
    }
)

(The user-defined type alias PointerArg still must be called with brackets, despite being basically a helper operator.)

Have a general mechanism for dot-notation accessible associated types

The main proposal is currently silent about exactly how Member and Param will have associated types for .name and .type.

We could just make it work for those particular types, or we could introduce a general mechanism that might look something like:

@typing.has_associated_types
class Member[
    N: str,
    T,
    Q: MemberQuals = typing.Never,
    I = typing.Never,
    D = typing.Never
]:
    type name = N
    type tp = T
    type quals = Q
    type init = I
    type definer = D

The decorator (or a base class) is needed if we want the dot notation for the associated types to be able to work at runtime, since we need to customize the behavior of __getattr__ on the typing._GenericAlias produced by the class so that it captures both the type parameters to Member and the alias.

(Though possibly we could change the behavior of _GenericAlias itself to avoid the need for that.)

Renounce all cares of runtime evaluation

This would give us more flexibility to experiment with syntactic forms, and would allow us to dispense with some ugliness such as requiring typing.Iter in unpacked comprehension types and having a limited set of <type-bool> expressions that can appear in conditional types.

For better or worse, though, runtime use of type annotations is widespread, and one of our motivating examples (automatically deriving FastAPI CRUD models) depends on it.

Support TypeScript style pattern matching in subtype checking

In TypeScript, conditional types are formed like:

SomeType extends OtherType ? TrueType : FalseType

What’s more, the right-hand side of the check allows binding type variables based on pattern matching, using the infer keyword, like this example that extracts the element type of an array:

type ArrayArg<T> = T extends [infer El] ? El : never;

This is a very elegant mechanism, especially in the way that it eliminates the need for typing.GetArg and its subtle Base parameter.

Unfortunately it seems very difficult to shoehorn into Python’s existing syntax in any sort of satisfactory way, especially because of the subtle binding structure.

Perhaps the most plausible variant would be something like:

type ArrayArg[T] = El if IsAssignable[T, list[Infer[El]]] else Never

Then, if we wanted to evaluate it at runtime, we’d need to do something gnarly involving a custom globals environment that catches the unbound Infer arguments.

Additionally, without major syntactic changes (using type operators instead of ternary), we wouldn’t be able to match TypeScript’s behavior of lifting the conditional over unions.

Replace IsAssignable with something weaker than “assignable to” checking

Full python typing assignability checking is not fully implementable at runtime (in particular, even if all the typeshed types for the stdlib were made available, checking against protocols will often not be possible, because class attributes may be inferred and have no visible presence at runtime).

As proposed, a runtime evaluator will need to be “best effort”, ideally with the contours of that effort well-documented.

An alternative approach would be to have a weaker predicate as the core primitive.

One possibility would be a “sub-similarity” check: IsAssignableSimilar would do simple checking of the head of types, essentially, without looking at type parameters. It would not work with protocols. It would still lift over unions and would check literals.

We decided it probably was not a good idea to introduce a new notion that is similar to but not the same as subtyping, and that would need to either have a long and weird name like IsAssignableSimilar or a misleading short one like IsAssignable.

Don’t use dot notation to access Member components

Earlier versions of this PEP draft omitted the ability to write m.name and similar on Member and Param components, and instead relied on helper operators such as typing.GetName (that could be implemented under the hood using typing.GetArg or typing.GetMemberType).

The potential advantage here is reducing the number of new constructs being added to the type language, and avoiding needing to either introduce a new general mechanism for associated types or having a special-case for Member.

PropsOnly (from the query builder example) would look like:

type PropsOnly[T] = typing.NewProtocol[
    *[
        typing.Member[typing.GetName[p], PointerArg[typing.GetType[p]]]
        for p in typing.Iter[typing.Attrs[T]]
        if typing.IsAssignable[typing.GetType[p], Property]
    ]
]

Everyone hated how this looked a lot.

Use type operators for conditional and iteration

Instead of writing:

• tt if tb else tf
• *[tres for T in Iter[ttuple]]

we could use type operator forms like:

• Cond[tb, tt, tf]
• UnpackMap[ttuple, lambda T: tres]
• or UnpackMap[ttuple, T, tres] where T must be a declared TypeVar

Boolean operations would likewise become operators (Not, And, etc).

The advantage of this is that constructing a type annotation never needs to do non-trivial computation (assuming we also get rid of dot notation), and thus we don’t need runtime hooks to support evaluating them.

It would also mean that it would be much easier to extract the raw type annotation. (The lambda form would still be somewhat fiddly. The non-lambda form would be trivial to extract, but requiring the declaration of a TypeVar goes against the grain of recent changes.)

Another advantage is not needing any notion of a special <type-bool> class of types.

The disadvantage is that the syntax seems a lot worse. Supporting filtering while mapping would make it even more bad (maybe an extra argument for a filter?).

We can explore other options too if needed.

Perform type manipulations with normal Python functions

One suggestion has been, instead of defining a new type language fragment for type-level manipulations, to support calling (some subset of) Python functions that serve as kind-of “mini-mypy-plugins”.

The main advantage (in our view) here would be leveraging a more familiar execution model.

One suggested advantage is that it would be a simplification of the proposal, but we feel that the simplifications promised by the idea are mostly a mirage, and that calling Python functions to manipulate types would be quite a bit more complicated.

It would require a well-defined and safe-to-run subset of the language (and standard library) to be defined that could be run from within typecheckers. Subsets like this have been defined in other systems (see Starlark, the configuration language for Bazel), but it’s still a lot of surface area, and programmers would need to keep in mind the boundaries of it.

Additionally there would need to be a clear specification of how types are represented in the “mini-plugin” functions, as well as defining functions/methods for performing various manipulations. Those functions would have a pretty big overlap with what this PEP currently proposes.

If runtime use is desired, then either the type representation would need to be made compatible with how typing currently works or we’d need to have two different runtime type representations.

Whether it would improve the syntax is more up for debate; I think that adopting some of the syntactic cleanup ideas discussed above (but not yet integrated into the main proposal) would improve the syntactic situation at lower cost.

Make the type-level operations more “strictly-typed”

This proposal is less “strictly-typed” than typescript (strictly-kinded, maybe?).

Typescript has better typechecking at the alias definition site: For P[K], K needs to have keyof P…

We could do potentially better but it would require more machinery.

• KeyOf[T] - literal keys of T
• Member[T], when statically checking a type alias, could be treated as having some type like tuple[Member[KeyOf[T], object, str, ..., ...], ...]
• GetMemberType[T, S: KeyOf[T]] - but this isn’t supported yet. TS supports it.
• We would also need to do context sensitive type bound inference

What exactly are the subtyping (etc) rules for unevaluated types

Because of generic functions, there will be plenty of cases where we can’t evaluate a type operator (because it’s applied to an unresolved type variable), and exactly what the type evaluation rules should be in those cases is somewhat unclear.

Currently, in the proof of concept implementation in mypy, stuck type evaluations implement subtype checking fully invariantly: we check that the operators match and that every operand matches in both arguments invariantly.