2024 Python Typing Survey Analysis

2024 Python Typing Survey Analysis

Overview

With help from the Pylance team at Microsoft and PyCharm at JetBrains, we’ve run a survey on typed Python since late July. I wanted to give an update with two weeks of data. Overall, I am thrilled at the number of responses so far. Here are some key stats:

  • 730 responses as of August 17th, the date of this analysis (750 as of posting)
  • 91% of respondents saying they use types “Always” or “Often”
  • 66% of respondents use Mypy
  • 65% of respondents use Pydantic
  • 35% of respondents use Pyright
  • 9 respondents said they love “nothing” about Python’s type system, yet 5 of them said they use types “Always”

It makes sense that a survey about types is going to get higher responses from type enthusiasts. If folks are interested in sharing this through other channels to help get more responses, I would greatly appreciate it. I’m tempted to sell it as something a little more pessimistic to try to get feedback from typing skeptics. Feel free to share in your own words if you like.

“Never use types in Python? Let the typing community know why. We’re running a survey for typed Python: https://2ly.link/1zN7s

Of the folks responding “Never” or “Rarely” use types, the majority of reasons they found types most helpful was for “Documentation,” “Faster Code Review,” and “Preventing Bugs”.

Despite overwhelming support for using types, the most common reason for not using types was:

  • Not Required for Project
  • Type Checking is too hard to use/set up

Data Explorer

I did my best to export data to Google’s looker studio to make it easier to visualize and look at cross tabs of the various survey results. Open to feedback for how to better represent the data.

I’m happy to share the raw data with folks who would like to do their own analysis. I haven’t had a chance to fully scrub any PII or other free-form data that may not be suitable for public release.

Noteable Feedback

Hardest parts about using the Python type system, along with relevant quotes:

1. Expressing Complex or Dynamic Features

  • Dynamic Features: Many respondents find it difficult to correctly express runtime dynamic features in the type system.
    • Quote: “The hoops you sometimes have to jump through to at least somewhat correctly express runtime dynamic features.”
  • Metaprogramming: There is a struggle to express metaprogramming patterns, like small DSLs.
    • Quote: “No good way to express metaprogramming like small DSLs.”
  • Edge Cases: Handling complex edge cases, especially those involving generics or complex constructs, is challenging.
    • Quote: “The very complex generic types involving more complicated type constructs.”

2. Inconsistencies and Divergent Behavior

  • Inconsistent Type Checkers: Different type checkers and IDEs often have divergent behavior, leading to confusion and frustration.
    • Quote: “Type checker divergent behavior creates situations where something well-typed isn’t understood by some user’s tooling.”
  • Library Support: Lack of standardization in type hints across libraries makes it difficult to maintain consistent typing.
    • Quote: “The type system is inconsistent in places, making robust solutions to certain problems hard or not possible.”

3. Lack of Documentation and Examples

  • Learning Curve: Respondents feel that advanced features in the type system are difficult to learn due to a lack of useful examples and clear documentation.
    • Quote: “Lack of useful examples of newer and more advanced typing features with higher entry-threshold.”
  • Poor Documentation: Limited or overly academic documentation hampers the ability to effectively use advanced typing features.
    • Quote: “Docs are sometimes too academic.”

4. Performance Issues

  • Slow Type Checkers: Tools like MyPy are often cited as being too slow, which hampers development speed.
    • Quote: “Mypy is so slow.”
  • Tooling Overhead: The additional setup and overhead required for type checking can be a deterrent.
    • Quote: “Checking types requires additional setup beyond Python.”

5. Fragmentation and Compatibility Issues

  • Version Fragmentation: Differences in type support across Python versions create additional complexity.
    • Quote: “Different versions of Python supporting different type hints.”
  • Tool Fragmentation: Using different tools with varying capabilities adds to the challenge.
    • Quote: “Different projects using different typing tools and configurations.”

6. Complexity of Advanced Typing Features

  • Generics and Variance: Many find generics, variance, and other advanced features like covariance/contravariance difficult to grasp and use effectively.
    • Quote: “Covariance/contravariance; overloads.”
  • Type Signatures: Complex type signatures, especially in decorators or higher-order functions, are hard to type correctly.
    • Quote: “Complex types get messy, you start moving them into classes.”

7. Interoperability with Non-Typed Libraries

  • Lack of Typing in Libraries: The absence of type hints in third-party libraries is a common complaint, as it complicates integration and type checking.
    • Quote: “Most python libraries have evolved for years without typing, consequently, things that would have been considered bugs if typing had been set up initially are now features.”

8. Loss of Flexibility and Readability

  • Verbose and Unreadable Syntax: The syntax can become verbose and detract from the readability of the code.
    • Quote: “When type hints start getting abstract and verbose and hurt readability.”
  • Loss of Flexibility: The type system can sometimes be seen as limiting the flexibility that Python developers are accustomed to.
    • Quote: “The trade-off between catching errors early and maintaining code flexibility is the hardest part.”

9. Cultural and Adoption Challenges

  • Resistance from Team Members: Some struggle with getting team members to adopt type hinting consistently.
    • Quote: “Working with teammates that don’t want to use it :-/”
  • Legacy Codebases: Retrofitting type hints into legacy codebases can be particularly challenging.
    • Quote: “Adopting it in a legacy codebase.”

10. Runtime vs. Static Typing

  • Runtime and Static Typing Discrepancy: The differences between runtime and type-checking-time behavior can lead to issues.
    • Quote: “Runtime/type-checking-time differences.”

Love about Python type hints, along with relevant quotes:

1. Improved Code Quality and Bug Prevention

  • Catching Bugs: Type hints help catch errors before runtime, improving code reliability.
    • Quote: “It finds real bugs. It often points to design flaws when typing is hard or impossible.”
  • Error Detection: The integration with IDEs allows for early error detection.
    • Quote: “Prevents bugs in runtime.”

2. Enhanced Readability and Maintainability

  • Clarity of Code: Type hints make code easier to read, understand, and maintain.
    • Quote: “It makes the code orders of magnitude more maintainable. They make it readable, auditable, easier to write.”
  • Documentation: They double as both documentation and code, making it easier to revisit code after some time.
    • Quote: “Documentation and linting all in one.”

3. IDE Support and Developer Experience

  • Autocomplete: Type hints significantly enhance the autocomplete features in IDEs, making coding faster and more accurate.
    • Quote: “Amazing autocomplete.”
  • Editor Integration: The integration with IDEs not only aids in writing code but also in understanding and navigating through it.
    • Quote: “IDE support for autocompletion. Knowing what is in front of you.”

4. Flexibility and Optional Usage

  • Optional Nature: Developers appreciate that type hints are optional, allowing for gradual adoption.
    • Quote: “I love that they’re optional, and that they support Protocols.”
  • Gradual Typing: Type hints can be introduced progressively, making them suitable for both new projects and existing codebases.
    • Quote: “Its flexibility - you can write an untyped script as a prototype, and gradually add type hints to it as it matures.”

5. Documentation and Self-Documentation

  • Code as Documentation: Type hints serve as self-documentation, making it clear what types are expected without needing additional comments.
    • Quote: “They dual serve as documentation and tests.”
  • API Clarity: They help clarify the API, making it easier to understand function signatures and expected input/output.
    • Quote: “Clearer API specification.”

6. Improved Refactoring

  • Refactoring Support: Type hints make it easier to refactor code by providing a clear understanding of data types throughout the codebase.
    • Quote: “Refactoring code becomes a lot easier.”
  • Confidence in Changes: They give developers confidence when making changes, reducing the risk of introducing bugs.
    • Quote: “They help me get new code working faster, help me avoid breaking things when making changes.”

7. Enhanced Reasoning and Design

  • Reasoning About Code: Type hints help in reasoning about code, especially when dealing with complex logic or data flows.
    • Quote: “Static types genuinely make it much easier to reason about code, and the flow of data.”
  • Design Feedback: The process of adding type hints can reveal design flaws or areas for improvement.
    • Quote: “Fixing type checker errors raises structural issues in code, leading to better code.”

8. Specific Features and Use Cases

  • Pydantic and FastAPI: Type hints work well with libraries like Pydantic and FastAPI, making API development smoother.
    • Quote: “When combining with e.g. Pydantic, it makes life a lot easier when building API for ML/AI systems.”
  • Runtime Features: Some developers appreciate that type hints can be used at runtime, enabling advanced use cases.
    • Quote: “The fact that they exist at runtime, allowing smart metaprogramming tricks in library code.”

9. Increased Productivity

  • Speeding Up Development: Type hints contribute to faster development by making code easier to write and understand.
    • Quote: “They allow me to produce better code faster.”
  • Reducing Cognitive Load: They reduce the mental effort required to keep track of types, making coding less error-prone.
    • Quote: “Function definitions are more readable and reduced cognitive load.”

10. General Enthusiasm

  • Positive Reception: Many developers express overall enthusiasm for type hints, praising their simplicity, power, and the improvements they bring to Python.
    • Quote: “Everything. Types are good.”

Missing from the Python type system, along with relevant quotes:

1. Intersection Types and Advanced Type Features

  • Intersection Types: Many respondents mention the need for intersection types, which allow for more expressive typing by combining multiple types.
    • Quote: “Intersection types, variadic generic transformation, true ‘never’ type, better support for metaclasses, etc.”
  • Higher-Kinded Types (HKT): There is a demand for higher-kinded types to enable more sophisticated generic programming.
    • Quote: “Higher kinded types, intersection types, basic dependent type support.”
  • Type Negation and Exclusion: Some developers desire more advanced features like type negation and exclusion.
    • Quote: “Intersections, Higher kinded types, Type negation/exclusion, sensible overloads.”

2. Runtime Type Enforcement

  • Runtime Type Checking: Developers express the need for built-in runtime type enforcement, rather than relying on external tools.
    • Quote: “There should be a way to enforce typing during runtime, without the need of some external tool.”
  • Runtime Assertions: The ability to enforce types at runtime would provide more immediate feedback and increase code safety.
    • Quote: “Runtime enforcement, runtime assertions/optimizations?”

3. Improved Typing for Complex and Dynamic Systems

  • Typing for Dynamic Code: There’s a call for better support for dynamic code generation and complex patterns like decorators and metaclasses.
    • Quote: “Better support for dynamic systems. A fast type checking system. Mypy is slow.”
  • Advanced Functional Programming Features: Some developers would like to see more support for functional programming patterns, such as higher-kinded types and composition abilities.
    • Quote: “Functional Programming type, such as Optional with composition ability, IO, Monad.”

4. Enhanced Tooling and IDE Support

  • Faster Type Checkers: Mypy and other type checkers are often cited as being too slow, and there’s a demand for faster alternatives.
    • Quote: “A faster mypy - mypy is the only pre-commit hook I cannot use, as it often takes 30s+ to run.”
  • Improved IDE Integration: Better IDE support and more consistent behavior across type checkers are desired to enhance the developer experience.
    • Quote: “Better/Standardized integration across IDEs.”

5. Stricter Typing and Enforcement

  • Mandatory Typing: Some respondents want an option to enforce typing strictly, making it mandatory rather than optional.
    • Quote: “An option to make it mandatory, and one to fail on build.”
  • Stricter Runtime Checks: There is interest in making type enforcement stricter, with options to ensure that types are followed rigorously during execution.
    • Quote: “Enforcement. If a variable is typed, it should refuse to take any other type.”

6. Advanced Type Inference and Automation

  • Better Type Inference: Developers want more powerful and consistent type inference that can reduce the need for explicit annotations.
    • Quote: “More powerful inference. The ability to reference the signature of another function in the manner of TypeScript.”
  • Automated Typing: Some wish for automated typing features, similar to what Rust or other languages offer, to simplify the process of adding types.
    • Quote: “Automating typing, kind of what Rust do.”

7. Documentation and Learning Resources

  • Better Documentation: There is a need for more comprehensive and accessible documentation, particularly for advanced type features.
    • Quote: “Better examples? Or links to explanations in mypy results?”
  • Learning Resources: Some developers suggest adding introductory resources for algebraic type systems or more complex type concepts.
    • Quote: “A short introduction to algebraic type systems in documentation.”

8. Specific Type Features and Enhancements

  • ParamSpec and TypedDict Improvements: Enhancements to features like ParamSpec and TypedDict are requested to make them more versatile and easier to use.
    • Quote: “Not being able to express args/kwargs types for wrapper functions. Lack of features in TypedDict.”
  • Support for Advanced Generics: There’s a desire for more powerful and flexible generic typing, including better support for type variables and variadic generics.
    • Quote: “Higher order types, Tensor typing!”

9. Uniformity and Consistency

  • Consistency Across Tools: Developers want a more unified and consistent approach to type checking, reducing discrepancies between different tools.
    • Quote: “Conformance testing for type checkers, more broadly: alignment on poorly specified areas like generics.”
  • Built-in Type Checking: The need for a standardized, built-in type checker within Python itself is mentioned, to avoid reliance on third-party tools.
    • Quote: “Type checking built into Python itself.”

10. Meta-Programming and DSL Support

  • Improved Meta-Programming Support: There’s a call for better typing support for meta-programming techniques, such as decorators and metaclasses.
    • Quote: “Make it not fight against metaprogramming (metaclasses, decorators that change the function signature, etc.).”

Thanks again for the help and feedback in designing the survey! :smile: I’d like to run it until the end of August and do a full analysis at the end.

17 Likes

You might want to post this somewhere off the Typing channel. For obvious reasons, us typing malcontents will have this channel muted.
Also can we have the original URL instead of the shortened one? On a good day, URL shorteners are just unwanted trackers and on a bad day, they’re obfuscating a malicious link.

6 Likes

I also think you’d get a much better picture from this survey if the responses let you differentiate between I use typing/some typing tool because I want to versus I use it because I don’t get any say in the matter. It would probably explain your 5 respondents that use typing “Always” despite loving “Nothing” about it.

3 Likes

This is all good feedback. If/when we run the survey again, I would like to incorporate feedback from what info is missing/needs follow-up and also a more strategic approach to ensure it’s getting a good representation of opinions.

I have some idea of the different input channels correlating to when folks shared it through the different social channels, but collecting this more explicitly would help.

I use typing/some typing tool because I want to versus I use it because I don’t get any say in the matter .

Yeah, this is almost the opposite of “Pushback from coworkers/co-maintainers”. I could see reformatting the question: “Rate the following from 1-5 (least to most useful) for usefulness in your project. “5” is most useful.” to “why do you use types?” and having one of the responses be essentially “because I have to.”

The link to the survey without the shortener is available in my original post.

3 Likes

The first post in this thread leads to a design document — for quick reference, the link appears to be Python Typing Survey 2024

A

2 Likes