From 3c8fd5abd0f1140f65a755515ddcd5e659e4fe83 Mon Sep 17 00:00:00 2001 From: "Michael J. Sullivan" Date: Wed, 4 Feb 2026 19:45:44 -0800 Subject: [PATCH 1/2] Write a bunch about why I don't want mini-plugins --- pep.rst | 41 +++++++++++++++++++++++++++++++++++++++++ 1 file changed, 41 insertions(+) diff --git a/pep.rst b/pep.rst index 3536ec1..2249fca 100644 --- a/pep.rst +++ b/pep.rst @@ -1527,6 +1527,46 @@ worse. Supporting filtering while mapping would make it even more bad 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. + +Other potential advantages include simplifying the proposal and +potentially improving the syntax. + +We think 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 system +(see `Starlark <#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 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" ---------------------------------------------------- @@ -1586,6 +1626,7 @@ Footnotes .. _#prisma: https://www.prisma.io/ .. _#prisma-example: https://github.com/prisma/prisma-examples/tree/latest/orm/express .. _#qb-test: https://github.com/vercel/python-typemap/blob/main/tests/test_qblike_2.py +.. _#starlark: https://starlark-lang.org/ .. [#broadcasting] http://docs.scipy.org/doc/numpy/user/basics.broadcasting.html .. [#ref-impl] https://github.com/msullivan/mypy/tree/typemap From a2bfeb0f19b8b91bc38a7ac8301991a2915ac3dd Mon Sep 17 00:00:00 2001 From: "Michael J. Sullivan" Date: Thu, 5 Feb 2026 13:06:35 -0800 Subject: [PATCH 2/2] tweak --- pep.rst | 10 ++++------ 1 file changed, 4 insertions(+), 6 deletions(-) diff --git a/pep.rst b/pep.rst index 2249fca..cb2d299 100644 --- a/pep.rst +++ b/pep.rst @@ -1537,12 +1537,10 @@ 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. -Other potential advantages include simplifying the proposal and -potentially improving the syntax. - -We think 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. +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