Skip to content

Excessive use of generics #1207

Description

@samuelcolvin

I brought this up in slack with @dsp-ant, but I should create an issue to express my concerns.

Generics in Python come with a significant cognitive overhead and harm DX:

Python language servers and type checkers (such as those derived from pyright) mark generic types without generics set as "partially unknown" - so to write type safe python you need to set each generic parameter wherever you use that type.

This problem is exacerbated by:

  • IDEs having poor support for auto-completing generics
  • this packages documentation (the readme) not bothering to set the generics where types are used

When I was trying to use Context I spent some time trying to work out what to put in its three generics. The only place I found code that filled those generics was in pydantic-ai's unit tests.

You might well say "not everyone cares about type safety, not everyone use types". Good point. ... except, if you don't care about type safety, don't bother with types, or generics at all. The venn diagrams of "uses types" and "cares about generics" surely overlap completely?

In many cases a better alternative to generics is unions (provided you can know all the types which the base type might be generic in). The big advantage of unions over generics is you only have to pay the cognitive price for working out what the value is, and/or enforcing that type in type-checking if/when you're actually accessing the relevant attribute - unlike generics where you generally have to worry about the generic type even if you're not accessing the attribute.

Introducing a third generic type to Context in #816 seems like a mistake, but I guess it's too late now.

I suggest:

  • updating the documentation to set the generic types
  • type checking documentation so issues like this don't happen again
  • avoiding excessive/unnecessary use of generics in future - our rule of thumb at Pydantic: no more than two generics in public types

Activity

  1. dsp-ant commented on Jul 28, 2025

    @dsp-ant
    Member

    Thank you for bringing that up. I think that's totally fair. I think we still have chances to rethink how we do the SDK. I think we will have a significant change from v1.x of the Python SDK to a v2.0 and could, within bounds, make changes.

    I think the general rule of not more than two generics in public types seems fine!

  2. self-assigned this
    on Jul 28, 2025
  3. samuelcolvin commented on Jul 28, 2025

    @samuelcolvin
    MemberAuthor

    It's worth noting that this would probably all be easier if Python had higher kinded types, but we shouldn't be tempted to always use extra generics in the absence of HKT.

  4. added
    v2Affects the v2 line (2.x on main)
    ready for workEnough information for someone to start working on
    P1Significant bug affecting many users, highly requested feature
    on Oct 7, 2025
  5. Kludex commented on Dec 3, 2025

    @Kludex
    Member

    I'll revisit all generics on this repository and assess them. Maybe we just need proper default, and better names. Let's see.

  6. added
    breaking changeWill break existing deployments when updated without changes
    on Dec 5, 2025
  7. added
    needs decisionIssue is actionable, needs maintainer decision on whether to implement
    and removed
    ready for workEnough information for someone to start working on
    on Apr 17, 2026
  8. maxisbey commented on Jul 29, 2026

    @maxisbey
    Contributor

    Thanks for the report. Closing this as it's been fixed in v2, which is now released (see #2203). Feel free to reopen if you still hit it on v2.

    AI Disclaimer

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    P1Significant bug affecting many users, highly requested featurebreaking changeWill break existing deployments when updated without changesenhancementRequest for a new feature that's not currently supportedneeds decisionIssue is actionable, needs maintainer decision on whether to implementv2Affects the v2 line (2.x on main)

    Type

    No type

    Projects

    No projects

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions