#539: Catching up with the Python Typing Council

Summary of #539: Catching up with the Python Typing Council

by Michael Kennedy

1h 1m•March 6, 2026
Listen to Episode

Overview of #539: Catching up with the Python Typing Council

This episode of Talk Python to Me (host Michael Kennedy) interviews three members of the Python Typing Council—Yala Zylstra, Rebecca Chen, and Carl Meyer—about how Python typing is governed, where the language/spec and various type checkers agree or diverge, and practical guidance for developers on how much typing to adopt. The conversation touches on the council’s purpose, the typing specification at typing.python.org, new Rust-based type checkers (Pyrefly and Ty), TypeShed, runtime-type tooling (Pydantic, BearType), upcoming features (3.15), contentious design areas (numeric tower / float vs int semantics, strict Optional handling), and how typing interacts with AI/code-generation tools.

Guests & roles

  • Yala Zylstra — Typing Council member; works at OpenAI on developer productivity.
  • Rebecca Chen — Typing Council member; works at Meta on Pyrefly (Rust-based type checker & LSP).
  • Carl Meyer — Typing Council member; works at Astral on Ty (Rust-based type checker & LSP).
  • Additional Typing Council members mentioned: Eric (Traut) and Jukka (Lehtosalo) — forming a five-person council.

Key topics covered

  • Purpose and history of the Python Typing Council
    • Created to allow targeted, faster decisions and spec clarifications outside the full PEP process.
    • Maintains the typing specification (typing.python.org) and accepts changes at several levels (small docs edits → spec PRs → full PEPs).
  • typing.python.org specification
    • Consolidates and clarifies behavior spread across multiple PEPs.
    • Examples of council-driven clarifications: overload semantics and dataclass final-field interpretation.
  • The ecosystem of type checkers
    • New Rust-based checkers: Pyrefly (Meta) and Ty (Astral).
    • Differences across checkers exist by design or philosophy (e.g., inference aggressiveness, error noise).
    • Conformance tests and the spec have reduced wild-west behavior, but variance remains.
  • Notable contentious design areas
    • Numeric tower: semantics of float annotations and whether float implies int (and how that should behave in all cases).
    • Nullability / Optional semantics and strict-optional enforcement — historically contentious; MyPy has legacy non-strict-optional modes being removed in favor of strict optional behavior.
    • User-defined type guards (PEP changes) — required careful redesign for correct semantics.
  • Runtime vs static typing
    • Python annotations generally do not affect runtime; many tools (Pydantic, BearType) use annotations at runtime to enforce/validate or provide behavior.
    • From future import annotations and other runtime changes affect how annotations are stored and used.
  • TypeShed and stubs
    • Two parts: standard-library stubs (widely used, essential) and third-party stubs (useful but diminishing as more libraries ship inline types).
    • Policy: TypeShed stubs can be removed if the library ships its own types.
  • Interplay with language changes
    • Lazy imports (3.15) can add edge cases for type checkers (e.g., dataclass annotations may force imports).
    • Several typing features are being considered or entering stdlib (e.g., TypedDict improvements, disjoint basis, TypeForm PEP 747).
  • Types + AI/code-generation
    • Types act as useful guardrails and richer signals for AI code generation and automated tooling; recommended to include them in tool-driven feedback loops (e.g., “run type checker in CI/automation”).

Main takeaways & recommendations

  • The Typing Council exists to document, clarify, and evolve typing behavior more quickly and practically than the full PEP process allows.
  • If you want your type checking to be most effective, annotate your public API boundaries (public functions, return types, public attributes). That yields the most value for users, IDEs, and downstream consumers.
  • Avoid annotating obvious locals where type inference suffices — excessive local annotations add noise.
  • Running a type checker (or multiple checkers) in CI is valuable; prefer automation that enforces type-check passing as part of the development feedback loop.
  • Types help humans and tooling (including AI) read and reason about code, and they make editor features (inlay hints, completions) significantly better.
  • If you want to influence the type system, start discussions on discuss.python.org → open issues/PRs on the typing spec repo → propose a PEP for large changes.

Practical advice & action items

  • Annotate API boundaries (public funcs, returns, class attributes).
  • Use in-editor inlay hints (Pyrefly, Ty both support them) to reduce source noise while still getting type information.
  • Use TypeShed for missing stubs (pip-installable) when third-party libs don’t ship types.
  • Run a type checker in CI; consider automation that blocks merges if new type errors are introduced.
  • If you find spec gaps or want changes: open a discussion on discuss.python.org → follow up with PRs to typing.python.org for spec clarifications or write a PEP for major features.

Spec/process summary (how changes happen)

  • Small editorial clarifications: direct PRs to the typing spec repo (a few council members review).
  • Spec changes that alter interpretation: council-level PRs that require full sign-off from Typing Council members.
  • Major feature changes or language-level changes: PEPs submitted and handled via the broader Python governance process; the council can sponsor/recommend.

Notable insights & quotes

  • “One of the magic parts of Python typing is that it’s gradual — you can take as much of the complexity as you want.” — summary of council’s design ethos.
  • Council exists to make it easier to make small/medium changes to typing without full PEP overhead, and to give type checker implementations a common place to converge.
  • Types are both human documentation and an automated guardrail (useful for editors, type checkers, and AI workflows).

Upcoming/near-term items to watch

  • Python 3.15: lazy imports (and related edge cases for dataclasses/annotations); several typing clarifications landing in stdlib.
  • typing.python.org updates: TypedDict rewrite, clarifications, and smaller spec improvements.
  • PEPs in flight: TypeForm (PEP 747) and other typing-related PEPs; disjoint basis and other nitty-gritty improvements for narrowing/type inference.

Where to get involved / resources

  • typing.python.org — canonical typing specification and conformance docs.
  • discuss.python.org — start discussions, propose ideas, gather community feedback.
  • Typing spec repo — open PRs for clarifications or spec changes.
  • TypeShed repository — find and contribute stubs for stdlib and third-party libs.
  • Type checker projects:
    • Pyrefly (Meta) — Rust-based type checker and LSP (Rebecca).
    • Ty (Astral) — Rust-based type checker and LSP (Carl).
    • MyPy, Pyright, Pyre — established checkers with different philosophies.

If you want to influence Python typing, the council encourages proposals and community participation—start on discuss.python.org and follow up with spec PRs or PEPs as needed.