PEP 827: Type Manipulation

PEPs
22

IMO I think using normal python functions to do these kinds of type transformations should be reconsidered as I think that’s definitely the best option. Yes, it is quite complex to implement, although I am unsure why it would be significantly more complex than the current proposal. And it would, with a bit of care, make the code readable in a way that the current proposal never will be.

IMO:

  • Complexity for type checking implementers is less important than

  • Complexity for people writing type expression is less important than

  • Complexity for people using a typed library.

I agree that this proposal successfully reduces complexity for the last group, but I believe that we can reduce the complexity for the second group significantly by moving some of it into the first group.

We discuss this some in the PEP (PEP 827 – Type Manipulation | peps.python.org), though it is true that much of the focus there is seemingly on the first group. I think that using “normal python functions” for this does not reduce complexity for the second group nearly as much as it might appear:

  • They wouldn’t really be normal Python functions. They would be functions in a new sublanguage that includes some of python but not all of it, despite being written as Python functions in Python files, and which programmers would need to understand the boundaries of to use.
  • I think in practice most of the complexity in using this will be in the operators being used, not in the syntax, which would be approximately the same in a “normal Python functions” proposal
1 Like
23

This discussion, the related draft PEP and similar draft PEP I had are expressing a similar idea.

FWIW there’s indeed overlap between your WIP proposals and the PEP.

type Movie = <{'name': str, 'location': <{'city': str}>}>

This is very sensible and can easily be the next step if this PEP is accepted or even incorporated.

Our PEP is more broad as it also focuses on enabling Protocols, which I think are very important to support as a lot of Python APIs revolve around classes.

24

Minor point: The fact that you need[1] to “misuse” the term “operator” which currently has a clear meaning in python to mean something else instead of being able to just say “function” is IMO an indicator that this is a larger complexity jump than you are making it out to be. Most people if you told them that this PEP adds operators would be quite confused.

  1. Well, not strictly need, but decided to do so ↩︎