TypeForm: Spelling for a type annotation object at runtime

Typing
7

The second draft of the TypeForm PEP is ready for review.

Notable changes/additions since draft 1
  • Started using the terms “type expression” and “annotation expression” from the typing specification whereever possible/appropriate, rather than redefining equivalent terms inline.
    • “Special form” is still used in a few parts of the PEP, but hopefully in a manner consistent with the definition from the typing specification.
  • Noted that a TypeForm can hold almost any kind of type expression, but has some exceptions.
  • Restricted TypeForm to NOT recognize runtime-only representations of type expressions (like ForwardRef(...), GenericAlias(...), and others) since such runtime-only representations are not API (at least at this time).
  • Tweaked the subtyping rules to hopefully now be sound
  • Added a new §“How to Teach This” section outlining considerations when defining functions that take a TypeForm as input
  • Altered the interpretation of a bare TypeForm (lacking an argument like T) so that type checkers may infer the missing argument, rather than always assuming it is Any. This allows reducing repetition in code like StrType: TypeForm[str] = str by rewriting as the shorter StrType: TypeForm = str.
  • Mentioned that a TypeForm[...] value is itself a kind of TypeForm

I also added one Open Issue, whether the name “TypeForm” is best one to use, since the PEP’s current definition aligns less with the modern definition of “special form” (from the typing specification) and more with a “type expression”.

Let me know what you think.

3 Likes