- 2026 Python打字调查收到1 794份答复。
- 类型提示使用在三年中变化不大，但检查器选择发生了急剧变化。
- 在报告使用的检查对象中，半数选择了一个以上，缺少的图书馆类型信息是最常见的困难。
我们连续第三年询问了Python开发者如何使用并体验了Python打字：语言特征，规格，以及用于描述并检查Python代码类型的工具。 我们进行调查是为了了解什么是可行的，什么是图书馆维护者、工具建设者、文件作者和标准贡献者下一步应该处理的问题。
大多数被调查者都是体验过Python开发者：76.4%的人使用Python至少5年。 最明显的变化是检查器选择的转变，而缺少的库类型信息仍然是最常见的困难。
2026Python打字调查的关键外卖
今年的调查结果显示，一些机会一再出现：
更广泛更准确的类型信息会帮助数据科学包的用户：动态框架构成不同的挑战，因为当前类型系统无法表达出一些运行时的行为。 可能的方向包括针对各个图书馆和框架的新的打字功能和检查器支持。
工具构建者可以专注于编辑器反馈和初始检查器运行，需要很少配置：出错消息可以链接到简短的解释和实例。 打字文档可以假设Python体验。 使用多种核对器的项目如能清楚地说明它们之间的有意差异，将是有益的。
更好的可调用语法仍然是标准工作的一个实际领域，特别是如果改进使常见的打字任务直截了当。
AI的用法仍然是一个有待解决的问题：关于AI的发现留下了一个关于AI工具与类型检查器之间哪些互动帮助开发者的问题。 进一步的经验研究可以为今后的设计提供参考。
AI 工具现在写入类型并回复检查出错
选择“使AI生成的代码更加准确/可靠”的答卷者比例从2025年的18.5%上升到2026年的38.4%。 AI工具为1,517个被调查者中的42.5%写出类型提示，而32.6%写出类型来改进AI生成的代码。 被调查者还使用AI修复或解释类型错误。 在列出的用于打字的AI工具的所有四项活动中，61.0%的受访者报告他们至少使用了其中之一。
一些应答者称他们的AI编码工具运行了检查器，然后修正出错。 在1,517个解答如何运行一个检查器的开发者中，24.4%，称一个AI编码工具引用了他们的检查器。 在370个被调查者中，61.6%的人还使用AI来修复检查器出错。 在其他人中，这一比例为19.3%。
有些受访者描述AI生成的种类过于宽泛
“我修补AI的编码型号提示，因为AI经常变得懒惰并使用对象来对待一切。”
“垃圾邮件型号的懒惰编码agents：忽略所有评论。”
当被问及人工智能辅助编码的实用性时，1 551个被调查者中有29.8%选择了“我不确定 ”。 AI辅助编码的不确定性率是运行时间保障率的7.7%的近4倍，是6种福利中次高的。 我们还需要经验证据，证明哪些相互作用确实有帮助。
Pyrefly团队已经在研究AI编码工具和类型检查器如何合作。 在2026 Python打字峰会上，团队介绍了"代理工作流中的类型检查"(Type Checking in Agentic Workflows).
库缺口总体领先；偶尔用户与复杂性斗争
第三方图书馆缺少类型信息是主要困难，在1 486个答卷人中，65.1%的人选择了这些信息。 另外44.6%的称类型系统无法描述他们的代码所做的一切。
开发者在图书馆轮船有专用活字节后，仍然可以拥有较差的经验。 在自己写出答案的156人中，有22人描述了动态构造，装饰者，元编程，或框架行为。 10个描述的阵列，数据框，或科学打字，至少有8个描述的注释不准确，不完整，或过于宽泛。 被调查者多次命名为Django,SQLAlchemy,Pydantic,Numby，熊猫和极地。
“Django做很多黑魔法
图书馆维护者需要说明，能够捕捉框架和数据科学图书馆的行为。 Pyrefly团队一直与Quansight合作改善第三方图书馆打字，包括对熊猫-stubs和NumPy的贡献。
使用频率发生变化，问题突出。 在很少或有时使用类型提示的开发者中，41.6%的人发现类型系统过于复杂或动词。 在经常使用或总是使用类型提示的开发者中，比例为14.5%. 缺少库打字影响了36.2%的低频组和70.0%的高频组。
“我使用直截了当的部分，避免难以理解的部分。”
多年的打字经验显示出不同的模式。 有18.2%的打字经验为0至2年的答卷者报告了复杂性，16.0%的答卷者报告了3至6年的情况，21.0%的答卷者报告了7年或7年以上的情况。 更新型的打字用户往往是普通用户并体验了Python开发者：在有0到2年打字经历的396名被调查者中，有306人(77.3%)经常或总是使用类型提示，有345人(87.1%)至少使用过Python3年。
对刚开始打字的开发者的指导，应当假设Python体验，并显示如何将类型添加到现有的寄存器中。 偶尔用户需要一个有用的首个检查，配置很少，容易理解的错误。 当我们改变类型系统时，我们应力求支持更多的模式，而不要使共同任务更加困难。
更好的可调用语法是一个实用的起步地。 在回答问题的1 486个答复者中，45.7%的人选择了该特征。 对报告复杂程度和其余样本的答复者来说，选择率相似。
新建跳棋获得地面快速
在三次调查中，常见的型号提示使用率保持在85.5%至88.0%之间：2024年为88.0%,2025年为85.9%,2026年为85.5%. 每年都有不同的小组作出答复，但总比率保持不变。
检查员的选择远没有那么稳定。 当2024年Python打字调查询问Python类型系统中缺少什么特征时
“一个更快的Mypy。 其速度的缺乏导致了生态系统的分解，而其他类型的检查者并不支持Mypy插件，而且一般行为也不同。 – 调查被调查者回答。
至2026年，开发者有数个较新的开源跳棋可供选择。 速度或性能是选择跳棋的原因，为56.5%。 使用这两年相同的跳棋榜单，2026年49.9%选择了两个或两个以上，比2025年的46.0%有所上升。
整个工作流程的开发者混合检查器
在选择了Mypy的700位被调查者中，297人也选择了它的编辑插件。 另有314在不选择Mypy插件的情况下选择了不同的命名检查器集成。
多数飞虫被调查者也选择了另一个检查器：264人中有220人，占83.3%. 在自由文本回复中，开发者描述了他们的团队为何在检查器之间划分工作：
“由于我的团队成员使用不同的IDE，我们使用多种类型检查器进行开发，但依靠Mypy进行林入(当地和CI)。”
当地我们主要使用Pyright，因为这是我们唯一尝试的，在CI/CD中，我们进行Pyrefly运行，只在Pyrefly失败的文件上运行Pyright，以提高检查的性能。”
在回答困难问题的1,486名开发者中，33.3%的人报告了跳棋之间的不一致。 在选择多个静态检查器并回答难度问题的738个答卷人中，有315人(42.7%)报告了检查器之间的不一致。
IDE 支持保留中枢作为打字帮助移出堆栈过度流
可读性或文档是使用类型提示的最有选择的原因，在1 571名被调查者中，93.6%的人选择了这种提示。 编辑支持排名也很高：在给出数字评价的1 494人中，84.8%选择了4或5. 提供自己理由的103个开发者中约有39%提到完成，导航，徘徊信息，或编辑出错消息。
“从理论上改进IDE工具提示/自动完成。”
实时编辑反馈普遍：1,517个被调查者中有82.9%在编辑器中运行了类型检查器。 维基百科代码是选择最多的编辑器或IDE，为59.3%.
开发者寻找帮助的地方也发生了变化。 从2024年到2026年，Stack Overflow使用率从46.4%下降到22.9%，而大型语言模型(LLM)聊天率从26.0%上升到41.7%. Python打字文档从56.2%上升到65.9%. 特定检查者文件的完成率为60.5%，比2025年的下降后52.2%有所增加。 Python通用文档从66.7%下降到62.2%.
随着开发者从 Stack Overflow 转向打字和检查器特定文档，这些来源的质量更为重要。 出错信息应链接到简短的相关解释和实例。 与文件的链接还将为LLM聊天工具提供更好的信息来配合。
调查结果和原始数据
下载2026年平顶山打字调查的全部结果和数据。
鸣谢
调查从8月5日至2026年9月2日。 它的开发得到了Pyrefly团队在Meta,PyCharm团队在JetBrains,Python团队在Microsoft,Ty团队在Astral/OpenAI以及社区贡献者在讨论上的支持.python.org. 我们通过Reddit,X,Mastodon，通讯，Python打字论坛，LinkedIn,Bluesky,Discord,Slack，以及类型校验项目网站和社会账号来分享。 我们轻而易举地编辑了引文，用于拼写、语法和发音。 我们感谢所有作出答复、分享调查、审查数据或为Python打字界作出贡献的人。
本文由 AI宝库自动抓取并翻译，版权归原作者所有；如需查看原文请点下方链接。
- The 2026 Python Typing Survey received 1,794 responses.
- Type hint use changed little across three years, but checker selection changed sharply.
- Among respondents who reported which checkers they use, half selected more than one, and missing library type information was the most common difficulty.
For the third consecutive year, we asked Python developers how they use and experience Python typing: the language features, specifications, and tools used to describe and check types in Python code. We run the survey to learn what is working and what library maintainers, tool builders, documentation authors, and standards contributors should tackle next.
Most respondents were experienced Python developers: 76.4% had used Python for at least five years. The clearest change was the shift in checker choice, while missing library type information remained the most common difficulty.
Key Takeaways From the 2026 Python Typing Survey
This year’s findings show several recurring opportunities:
Broader and more accurate type information would help users of data-science packages: Dynamic frameworks pose a different challenge because current type systems cannot express some runtime behavior. Possible directions include new typing features and checker support tailored to individual libraries and frameworks.
Tool builders could focus on editor feedback and an initial checker run that requires little configuration: Error messages could link to short explanations and examples. Typing documentation can assume Python experience. Projects using multiple checkers would benefit from clear explanations of intentional differences between them.
Better callable syntax remains a practical area for standards work, especially if improvements keep common typing tasks straightforward.
AI usage remains an open question: The findings on AI leave an open question about which interactions between AI tools and type checkers help developers. Further empirical study could inform future designs.
AI Tools Now Write Types and Respond to Checker Errors
The share of respondents who selected “Makes AI-generated code more accurate/reliable” rose from 18.5% in 2025 to 38.4% in 2026. AI tools wrote type hints for 42.5% of 1,517 respondents, while 32.6% wrote types to improve AI-generated code. Respondents also used AI to fix or explain type errors. Across all four activities listed for AI tool use in typing, 61.0% of respondents reported they used at least one of these options.
Some respondents said their AI coding tool runs the checker and then fixes the errors. Of the 1,517 developers who answered how they run a checker, 24.4%, said an AI coding tool invoked their checker. Among the 370 respondents, 61.6% also used AI to fix checker errors. The rate was 19.3% among everyone else.
Some respondents described AI-generated types that are too broad and agents that suppress checker errors:
“I fix AI coded type hints because AI often gets lazy and uses object for everything.”
“Lazy coding agents that spam #type: ignore comments everywhere.”
When asked how useful types are for better AI-assisted coding, 29.8% of 1,551 respondents chose “I’m not sure.” The uncertainty rate for AI-assisted coding was nearly four times the 7.7% rate for runtime guarantees, the next-highest of the six benefits. We still need empirical evidence about which interactions actually help.
The Pyrefly team is already studying how AI coding tools and type checkers work together. At the 2026 Python Typing Summit, the team presented Type Checking in Agentic Workflows.
Library Gaps Lead Overall; Occasional Users Struggle With Complexity
Missing type information in third-party libraries was the leading difficulty, selected by 65.1% of 1,486 respondents. Another 44.6% said the type system could not describe everything their code does.
Developers can still have a poor experience after a library ships dedicated stubs. Among 156 people who wrote their own answer, 22 described dynamic constructs, decorators, metaprogramming, or framework behavior. Ten described arrays, dataframes, or scientific typing, and at least eight described annotations that were inaccurate, incomplete, or too broad. Respondents repeatedly named Django, SQLAlchemy, Pydantic, NumPy, pandas, and Polars.
“Django does so much black magic it’s a wonder a type checker works at all.” — survey respondent
Library maintainers need annotations that capture how frameworks and data-science libraries behave. The Pyrefly team has been working with Quansight to improve third-party library typing, including contributions to pandas-stubs and NumPy.
Frequency of use changed which problems stood out. Among developers who used type hints rarely or sometimes, 41.6% found the type system too complex or verbose. The rate was 14.5% among developers who used type hints often or always. Missing library typing affected 36.2% of the lower-frequency group and 70.0% of the higher-frequency group.
“I use the straightforward parts and avoid the parts that are difficult to understand.” — survey respondent.
Years of typing experience showed a different pattern. Complexity was reported by 18.2% of respondents with zero to two years of typing experience, 16.0% with three to six years, and 21.0% with seven or more. Newer typing users were often regular users and experienced Python developers: Of the 396 respondents with zero to two years of typing experience, 306 (77.3%) used type hints often or always and 345 (87.1%) had used Python for at least three years.
Guidance for developers who are new to typing should assume Python experience and show how to add types to an existing repository. Occasional users need a useful first check with little configuration and easy-to-understand errors. As we change the type system, we should aim to support more patterns without making common tasks harder.
Better Callable syntax is one practical place to start. It was the most selected missing feature, chosen by 45.7% of the 1,486 respondents who answered the question. The selection rate was similar for respondents who reported complexity and the rest of the sample.
Newer Checkers Gained Ground Quickly
Frequent type hint use remained between 85.5% and 88.0% across the three surveys: 88.0% in 2024, 85.9% in 2025, and 85.5% in 2026. A different group answered each year, but the overall rate remained consistent.
Checker choice was far less stable. When the 2024 Python Typing survey asked what feature was missing from the Python type system, one response now reads like a preview of the changes captured in this year’s results:
“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.” – survey respondent
By 2026, developers had several newer open-source checkers to choose from. Speed or performance topped the reasons for choosing a checker, at 56.5%. Using the same list of checkers in both years, 49.9% selected two or more in 2026, up from 46.0% in 2025.
Developers Mix Checkers Across Their Workflows
Of the 700 respondents who selected Mypy, 297 also selected its editor plugin. Another 314 selected a different named checker integration without selecting the Mypy plugin.
Most Pyrefly respondents also selected another checker: 220 of 264, or 83.3%. In the free-text responses, developers described why their teams divide work between checkers:
“Because my team members use different IDEs, we use multiple type checkers for development, but rely on Mypy for linting (local and CI).” — survey respondent
“Locally we primarily use Pyright because it’s the only option we’ve tried that fully understands all the more niche typing patterns within our codebase. In CI/CD, we do a Pyrefly run and only run Pyright on files where Pyrefly fails, to improve performance of the check.” — survey respondent
Among the 1,486 developers who answered the question about difficulties, 33.3% reported inconsistencies between checkers. Among the 738 respondents who selected multiple static checkers and answered the difficulty question, 315 (42.7%) reported inconsistencies between checkers.
IDE Support Remains Central as Typing Help Moves Away From Stack Overflow
Readability or documentation was the most selected reason to use type hints, chosen by 93.6% of 1,571 respondents. Editor support also ranked highly: 84.8% of the 1,494 people who gave it a numeric rating chose 4 or 5. About 39% of the 103 developers who supplied their own reason mentioned completion, navigation, hover information, or editor error messages.
“Drastically improves IDE tooltip/autocomplete.” – survey respondent
Real-time editor feedback was widespread: 82.9% of 1,517 respondents ran a type checker in an editor. VS Code was the most selected editor or IDE, at 59.3%.
Where developers look for help has changed as well. From 2024 to 2026, Stack Overflow use fell from 46.4% to 22.9%, while large language model (LLM) chat rose from 26.0% to 41.7%. Python typing documentation rose from 56.2% to 65.9%. Checker-specific documentation ended at 60.5%, up from 52.2% after a dip in 2025. General Python documentation fell from 66.7% to 62.2%.
As developers move from Stack Overflow to typing- and checker-specific documentation, the quality of those sources matters more. Error messages should link to short, relevant explanations and examples. Links to documentation would also give LLM chat tools better information to work with.
Survey Results and Raw Data
Download the full results and data from the Python Typing Survey 2026.
Acknowledgements
The survey ran from August 5 through September 2, 2026. It was developed with support from the Pyrefly team at Meta, the PyCharm team at JetBrains, the Python team at Microsoft, the ty team at Astral/OpenAI, and community contributors on discuss.python.org. We shared it through Reddit, X, Mastodon, newsletters, the Python typing forum, LinkedIn, Bluesky, Discord, Slack, and type-checker project websites and social accounts. We lightly edited quotations for spelling, grammar, and punctuation. We thank everyone who responded, shared the survey, reviewed the data, or contributed to the Python typing community.
Auto-fetched and translated by AI Gem Box. All rights belong to the original author.