PEP 747: TypeExpr: Type Hint for a Type Expression

Typing
41

I’ve drafted a PR that:

  • Rephrases the rules for the | operator to just say that situations that previously resulted in a UnionType static type should now result in a TypeExpr[X | Y] static type, rather than attempting to directly specify the existing complex (and undocumented?) rules for the | operator.
  • Removes the ability to assign a TypeExpr[X | Y] to a UnionType, which implies a backward compatibility break for the rare functions that use UnionType in their signature. Migration guidance is added to §“Backward Compatibility”.

Feedback is welcome.

After the above items are ironed out, I’ll move on to altering the name of the concept that PEP 747 introduces, which I expect will be a monster of a diff.

1 Like
42

I’ve drafted a replacement PR that takes a different approach:

  • No longer attempts to alter the rules for the | operator. Thus users must use the explicit TypeExpr(...) syntax in code using |, like the following:

    if isassignable(x, TypeExpr(int | str)): ...  # TypeExpr(...) required

Feedback is welcome.

43

Update on the overall status of PEP 747: Remaining tasks I see:

  • Address remaining major points of feedback. Achieve rough consensus:
    • A1. :white_check_mark: T1 | T2: Decide how/whether to recognize type expressions that use | in a value expression context
    • A2. :arrow_forward: Finalize the name of the concept that the PEP introduces.
  • Draft a reference implementation for at least 2 static type checkers. Discover/resolve any specification issues.
    • B1. mypy - Probably drafted by me
    • B2. (?) pyright
  • C. Present PEP for formal review by Typing/Steering Councils
1 Like
44

A new draft of the TypeForm (previously: TypeExpr) PEP is ready for review in this PR! This latest draft is brought to you by @erictraut , a new co-author for the PEP.

Major changes include:

  • Refining and clarifying the terminology and definitions
    • ex: TypeExpr → TypeForm (biggest rename)
  • Eliminating the detailed implicit evaluation rules for every kind of type expression.
    • Instead, anything that conforms to the typing spec’s definition of a “type expression” should be accepted when assigned to a variable or passed to a function parameter that is explicitly annotated as TypeForm.

Please leave general comments in this thread and more-specific comments in the PR itself.

The next version of pyright (1.1.381), likely released Tues 9/17, will include provisional support for TypeForm as described in this draft. The new functionality is off by default, but it can be enabled by setting “enableExperimentalFeatures” to true in the pyright configuration.

I’m planning to work on mypy support for TypeForm over the next two weeks.

3 Likes