Skip to content

Commit 3c8fd5a

Browse files
committed
Write a bunch about why I don't want mini-plugins
1 parent 864d441 commit 3c8fd5a

1 file changed

Lines changed: 41 additions & 0 deletions

File tree

pep.rst

Lines changed: 41 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -1527,6 +1527,46 @@ worse. Supporting filtering while mapping would make it even more bad
15271527

15281528
We can explore other options too if needed.
15291529

1530+
Perform type manipulations with normal Python functions
1531+
-------------------------------------------------------
1532+
1533+
One suggestion has been, instead of defining a new type language
1534+
fragment for type-level manipulations, to support calling (some subset
1535+
of) Python functions that serve as kind-of "mini-mypy-plugins".
1536+
1537+
The main advantage (in our view) here would be leveraging a more
1538+
familiar execution model.
1539+
1540+
Other potential advantages include simplifying the proposal and
1541+
potentially improving the syntax.
1542+
1543+
We think that the simplifications promised by the idea are mostly a
1544+
mirage, and that calling Python functions to manipulate types would be
1545+
quite a bit *more* complicated.
1546+
1547+
It would require a well-defined and safe-to-run subset of the language
1548+
(and standard library) to be defined that could be run from within
1549+
typecheckers. Subsets like this have been defined in other system
1550+
(see `Starlark <#starlark_>`_, the configuration language for Bazel),
1551+
but it's still a lot of surface area, and programmers would need to
1552+
keep in mind the boundaries of it.
1553+
1554+
Additionally there would need to be a clear specification of how types
1555+
are represented in the "mini-plugin" functions, as well defining
1556+
functions/methods for performing various manipulations. Those
1557+
functions would have a pretty big overlap with what this PEP currently
1558+
proposes.
1559+
1560+
If runtime use is desired, then either the type representation would
1561+
need to be made compatible with how ``typing`` currently works or we'd
1562+
need to have two different runtime type representations.
1563+
1564+
Whether it would improve the syntax is more up for debate; I think
1565+
that adopting some of the syntactic cleanup ideas discussed above (but
1566+
not yet integrated into the main proposal) would improve the syntactic
1567+
situation at lower cost.
1568+
1569+
15301570
Make the type-level operations more "strictly-typed"
15311571
----------------------------------------------------
15321572

@@ -1586,6 +1626,7 @@ Footnotes
15861626
.. _#prisma: https://www.prisma.io/
15871627
.. _#prisma-example: https://github.com/prisma/prisma-examples/tree/latest/orm/express
15881628
.. _#qb-test: https://github.com/vercel/python-typemap/blob/main/tests/test_qblike_2.py
1629+
.. _#starlark: https://starlark-lang.org/
15891630

15901631
.. [#broadcasting] http://docs.scipy.org/doc/numpy/user/basics.broadcasting.html
15911632
.. [#ref-impl] https://github.com/msullivan/mypy/tree/typemap

0 commit comments

Comments
 (0)