@@ -1524,6 +1524,46 @@ worse. Supporting filtering while mapping would make it even more bad
15241524
15251525We can explore other options too if needed.
15261526
1527+ Perform type manipulations with normal Python functions
1528+ -------------------------------------------------------
1529+
1530+ One suggestion has been, instead of defining a new type language
1531+ fragment for type-level manipulations, to support calling (some subset
1532+ of) Python functions that serve as kind-of "mini-mypy-plugins".
1533+
1534+ The main advantage (in our view) here would be leveraging a more
1535+ familiar execution model.
1536+
1537+ Other potential advantages include simplifying the proposal and
1538+ potentially improving the syntax.
1539+
1540+ We think that the simplifications promised by the idea are mostly a
1541+ mirage, and that calling Python functions to manipulate types would be
1542+ quite a bit *more * complicated.
1543+
1544+ It would require a well-defined and safe-to-run subset of the language
1545+ (and standard library) to be defined that could be run from within
1546+ typecheckers. Subsets like this have been defined in other system
1547+ (see `Starlark <#starlark _>`_, the configuration language for Bazel),
1548+ but it's still a lot of surface area, and programmers would need to
1549+ keep in mind the boundaries of it.
1550+
1551+ Additionally there would need to be a clear specification of how types
1552+ are represented in the "mini-plugin" functions, as well defining
1553+ functions/methods for performing various manipulations. Those
1554+ functions would have a pretty big overlap with what this PEP currently
1555+ proposes.
1556+
1557+ If runtime use is desired, then either the type representation would
1558+ need to be made compatible with how ``typing `` currently works or we'd
1559+ need to have two different runtime type representations.
1560+
1561+ Whether it would improve the syntax is more up for debate; I think
1562+ that adopting some of the syntactic cleanup ideas discussed above (but
1563+ not yet integrated into the main proposal) would improve the syntactic
1564+ situation at lower cost.
1565+
1566+
15271567Make the type-level operations more "strictly-typed"
15281568----------------------------------------------------
15291569
@@ -1583,6 +1623,7 @@ Footnotes
15831623.. _#prisma : https://www.prisma.io/
15841624.. _#prisma-example : https://github.com/prisma/prisma-examples/tree/latest/orm/express
15851625.. _#qb-test : https://github.com/vercel/python-typemap/blob/main/tests/test_qblike_2.py
1626+ .. _#starlark : https://starlark-lang.org/
15861627
15871628.. [#broadcasting ] http://docs.scipy.org/doc/numpy/user/basics.broadcasting.html
15881629 .. [#ref-impl ] https://github.com/msullivan/mypy/tree/typemap
0 commit comments