Typed Python in 2024: Adoption is high, but tooling friction remains
JetBrains, Meta, and Microsoft have published the results of a joint survey into the state of Python typing, based on responses from over 1,000 developers. The goal was to map how type hints are used in the open source community, where they provide the most value, and where developers still struggle. The headline: 88% of respondents say they use types "Always" or "Often." But widespread adoption hasn't eliminated pain points with performance, documentation, and the language's dynamic features.
Survey data was collected online between 07/29/2024 and 10/08/2024, and distributed via social media channels targeting Python developers. The authors acknowledge the results are not a representative sample of the entire Python community, given that the topic likely skews toward typing enthusiasts.
Where types are used
Python's reach means typed usage cuts across domains, including scripting, web development, data analysis, AI/ML, DevOps, and teaching. Notably, the value of types is not restricted to shared codebases. Among respondents who only use Python for personal projects, 66% use types "Always" or "Often." Among those who never run type checking in CI, 29.6% report the same level of usage. Types are functioning as a development-time aid, not just a merge-gate feature.
Tools and environments
VS Code is the most popular editor among respondents, and the most common pairing is VS Code with Mypy, followed by PyCharm with Mypy. Mypy remains the dominant type checker, used by 67% of respondents. Pyright comes in at 38%, with a 24% overlap between the two. The Emacs/NeoVIM contingent is still sizable at 11% combined.
Runtime use of the type system is also significant. While not a static checker, Pydantic is used by 62% of respondents, and 14% rely on it as their only typing tool.
What developers value
The benefits of typing are concrete for most users. Enhanced autocompletion was rated the most useful feature by 59% of respondents. Bug prevention followed at 49.8%, with documentation value close behind at 49.2%. Respondents also highlighted the utility of catching errors early and easing refactors. The optional, gradual nature of adoption was praised, and some feedback suggests typing often surfaces design flaws as quickly as it catches bugs.
"It finds real bugs. It often points to design flaws when typing is hard or impossible."
Leading complaints
Freeform feedback revealed recurring frustrations. The most common concern, raised 29 times, is the difficulty of expressing dynamic features within the type system. The performance of type checkers like Mypy followed, cited by 22 respondents. Inconsistencies between different type checker implementations came third with 21 responses, while inadequate documentation, especially for advanced constructs, drew 10 complaints.
"Numerous libraries lack any type annotations, hindering code analysis and potentially leading to runtime errors."
"The hoops you sometimes have to jump through to at least somewhat correctly express runtime dynamic features, and even then they are often not correctly covered."
Why some developers skip types
321 respondents (29% of the total) shared why they do not type their Python code. The most common stated reason, "Not required for my projects," was cited by 11% of all survey participants. Yet even this group contains substantial typing usage: 60% among them say they use types "Always" or "Often," which is 28 points below the survey mean but still a meaningful share of a group that said types aren't required.
What tools need next
Across all cohorts, respondents asked for improved performance from type checkers, as well as greater standardization and consistency between tools. There is appetite for better support of dynamic and complex patterns, and for stronger runtime checking capabilities. The official typing documentation remains the go-to learning resource, tested by its status as the most popular path for gaining expertise. Yet many participants specifically requested more approachable documentation with practical examples for advanced features, particularly at an entry level where "lack of familiarity" was the second highest reason (8% of responses) for not adopting types.
