Python Typing Council

About the Typing Council

The Typing Council was created in PEP 729 to govern the Python type system. Its mandate is to ensure that the type system is useful, usable, and stable.

The current members of the Council are:

• Eric Traut (@erictraut)
• Carl Meyer (@carljm)
• Jelle Zijlstra (@JelleZijlstra)
• Rebecca Chen (@rchen152)
• Shantanu Jain (@hauntsaninja)

Decisions

The Council makes decisions in response to issues opened on this repo. Such decisions include:

• Substantive changes to the specification for the type system
• Recommendations on PEPs that relate to typing

Any such issues should first be discussed on discuss.python.org before being submitted for a decision.

Before the Council makes a decision, the community should get a chance to weigh in. The procedure for requesting a specification change without a PEP is:

1. Post on discuss.python.org about the topic
2. Once the decision has run its course, create a concrete proposal (i.e., a proposed change to the spec) and make a pull request on the python/typing repo.
3. Create an issue on this repo asking the Typing Council for a decision.
4. After at least a week, the Council will make a decision, which may be to accept the change, reject it, or modify it.

The following items will be helpful when proposing a change to the specification:

• A survey of the current behavior of major type checkers
• A rationale for why the proposed behavior is better than alternatives
• An implementation or proposed implementation of the proposed behavior in at least one major type checker

Purpose of this repo

This repo exists only as a place to record the Typing Council's procedures and to ask for decisions from the Council. No substantive discussions should take place on this repo.

Decision-making considerations

The Council is new and we will need time to figure out what works best. However, to help contributors, we are listing some factors we expect to consider when making decisions.

• What do type checkers currently do? Proposed spec changes should come with a survey of current type checker behavior. If all type checkers currently behave one way, but the spec says something else, we should almost certainly change the spec.
• Are type checkers willing to implement the proposed behavior? Often, there will be some disagreement among type checkers. If type checker maintainers aren't able or willing to change their tool’s behavior, we may not be ready for a change.
• Is the proposed behavior well-specified? Much of the current spec is vague. We should gradually work to improve that, and in particular new spec changes should be clear and unambiguous.
• Does the proposed change make the type system more consistent? If so, we are more likely to accept it.
• Is the proposed change sound (in the type-theoretic sense)? The Python type system is known to be not fully sound, and there are differing opinions on whether and to what extent we should aim to make it sound, but in general, a change that brings us closer to soundness is better.
• What are the backward compatibility implications of the change? We believe that it is important to keep the type system stable and avoid gratuitous compatibility breaks.
• What would be the effect of the change on real-world code checked by type checkers? Does it result in more false positives or false negatives?
• Does the proposed change make the type system better for our users?