There were 1,794 responses to the 2026 Python Typing Survey, collected between August 5 and September 2, 2026. This is the third year in a row the community has measured how developers use Python's type features, specifications and checking tools. The audience skews experienced: 76.4% of respondents had used Python for at least five years.
Hint usage stayed flat across the three years, at 88.0% in 2024, 85.9% in 2025 and 85.5% in 2026 among respondents who said they use type hints often or always (each year drew a different group of respondents). Checker selection, by contrast, moved sharply, and missing type information in third-party libraries remained the most commonly reported difficulty.
AI assistance moves from accuracy argument to production tool
The share of respondents picking "Makes AI-generated code more accurate/reliable" as a reason to use types climbed from 18.5% in 2025 to 38.4% in 2026. AI tools now do typing work directly: 42.5% of 1,517 respondents reported AI writing type hints, and 32.6% wrote types to shore up AI-generated code. Taken across all four listed AI-in-typing activities, 61.0% of respondents reported at least one.
Agents also interact with checkers. Of the 1,517 developers who described how they run their checker, 24.4% said an AI coding tool invoked it. Among the 370 respondents whose AI tool ran the checker, 61.6% also used AI to fix its errors, compared with 19.3% of everyone else. The results are not uniformly encouraging. Free-text answers described AI writing overly broad annotations (object for everything) and agents suppressing diagnostics:
"Lazy coding agents that spam #type: ignore comments everywhere."
Whether types actually help AI-assisted coding is unresolved: 29.8% of 1,551 respondents answered "I'm not sure" on that question, nearly four times the 7.7% uncertainty rate for runtime guarantees, the next-highest of six benefits. The Pyrefly team has begun work in this area and presented "Type Checking in Agentic Workflows" at the 2026 Python Typing Summit.
Where typing hurts: library coverage, then complexity
Missing type information in third-party libraries led the difficulty rankings at 65.1% of 1,486 respondents, followed by 44.6% who said the type system cannot describe everything their code does. Among 156 free-text respondents, 22 described dynamic constructs, decorators, metaprogramming or framework behavior; ten focused on arrays, dataframes or scientific typing; at least eight cited annotations that were inaccurate, incomplete or too broad. Django, SQLAlchemy, Pydantic, NumPy, pandas and Polars came up repeatedly. Stubs alone don't guarantee a good experience, as one respondent put it:
"Django does so much black magic it's a wonder a type checker works at all."
The Pyrefly team has worked with Quansight on third-party library typing, including contributions to pandas-stubs and NumPy.
How often someone uses typing changes which problem stings. Complexity or verbosity of the type system bothered 41.6% of occasional users (rarely or sometimes) against 14.5% of frequent users. Missing library typing showed the inverse: 36.2% in the occasional group versus 70.0% among frequent users.
"I use the straightforward parts and avoid the parts that are difficult to understand."
Time spent with typing shows its own curve: complexity was reported by 18.2% of those with zero to two years of typing experience, 16.0% at three to six years, and 21.0% at seven or more. Newcomers to typing are rarely new to Python — of the 396 respondents with at most two years of typing experience, 306 (77.3%) use hints often or always and 345 (87.1%) had used Python for at least three years. Practical follow-ups include tooling that gives a useful first run with little configuration and errors that are easy to read, typing docs that assume Python familiarity, and explanations of deliberate differences for projects running several checkers.
For standards work, better Callable syntax is the obvious candidate: it was the most-missed feature, chosen by 45.7% of the 1,486 respondents who answered, at similar rates among users reporting complexity and the rest. The guiding constraint is to widen what the system can express without complicating everyday typing.
Checker choice fragments, with speed as the driving reason
Speed or performance was the top reason for choosing a checker, named by 56.5% of respondents, and newer open-source checkers gained ground quickly. On an identical list of checkers, 49.9% of respondents selected two or more in 2026, up from 46.0% in 2025. More than one response to the 2024 survey anticipated this:
"A faster Mypy. Its lack of speed led to ecosystem fracturing and other type checkers don't support Mypy plugins and behave differently in general."
Selections overlap inside single workflows. Of the 700 Mypy users, 297 also picked its editor plugin, while 314 chose a different named checker integration without the Mypy plugin. Pyrefly users are overwhelmingly mixed: 220 of 264 (83.3%) also selected another checker. Respondents described the division of labour:
- Multiple checkers during development because team members use different IDEs, with Mypy kept for linting locally and in CI.
- Pyright locally for niche typing patterns in a codebase, Pyrefly in CI/CD, and Pyright run only on the files where Pyrefly fails to keep checks fast.
The cost of mixing shows up in the difficulty data: 33.3% of the 1,486 respondents to the difficulties question reported inconsistencies between checkers, and among the 738 who selected multiple static checkers, that figure reached 42.7% (315 respondents).
Editors carry the feedback loop; help has migrated off Stack Overflow
Readability and documentation were the leading reason to use type hints, selected by 93.6% of 1,571 respondents. Editor support followed closely, rated 4 or 5 by 84.8% of 1,494 respondents, and about 39% of 103 free-text reasons mentioned completion, navigation, hover information or in-editor error messages. One respondent summed it up as a drastic improvement to IDE tooltips and autocomplete.
Real-time checking is the norm: 82.9% of 1,517 respondents run a checker inside an editor. VS Code was the most selected editor or IDE at 59.3%.
Sources of help shifted between 2024 and 2026. Stack Overflow fell from 46.4% to 22.9%, while LLM chat rose from 26.0% to 41.7%. Python typing documentation rose from 56.2% to 65.9%, checker-specific documentation reached 60.5% (up from 52.2% after a 2025 dip), and general Python documentation declined from 66.7% to 62.2%. With that traffic going to typing and checker docs, their quality matters more. Error messages that link to short explanations and examples would serve both developers directly and LLM tools.
Method and data
The survey was developed with the Pyrefly team at Meta, the PyCharm team at JetBrains, the Python team at Microsoft, the ty team at Astral/OpenAI and contributors on discuss.python.org, and was distributed through Reddit, X, Mastodon, newsletters, the Python typing forum, LinkedIn, Bluesky, Discord, Slack, and type-checker project websites and accounts. Full results are available in the Python Typing Survey 2026 dataset.
