Repository navigation
Excessive use of generics #1207
Description
Activity
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!
Reacted by Samuel ColvinIt'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.
Reacted by David Soria Parra- added a parent issue
on Aug 9, 2025 - addedv2Affects the v2 line (2.x on main)Affects the v2 line (2.x on main)ready for workEnough information for someone to start working onEnough information for someone to start working onP1Significant bug affecting many users, highly requested featureSignificant bug affecting many users, highly requested feature
on Oct 7, 2025 - addedenhancementRequest for a new feature that's not currently supportedRequest for a new feature that's not currently supportedand removed
on Nov 12, 2025 I'll revisit all generics on this repository and assess them. Maybe we just need proper default, and better names. Let's see.
- addedbreaking changeWill break existing deployments when updated without changesWill break existing deployments when updated without changes
on Dec 5, 2025 - addedneeds decisionIssue is actionable, needs maintainer decision on whether to implementIssue is actionable, needs maintainer decision on whether to implementand removedready for workEnough information for someone to start working onEnough information for someone to start working on
on Apr 17, 2026 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.
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:
When I was trying to use
ContextI 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
Contextin #816 seems like a mistake, but I guess it's too late now.I suggest: