-
Notifications
You must be signed in to change notification settings - Fork 3.3k
Excessive use of generics #1207
Copy link
Copy link
Open
Labels
P1Significant bug affecting many users, highly requested featureSignificant bug affecting many users, highly requested featurebreaking changeWill break existing deployments when updated without changesWill break existing deployments when updated without changesenhancementRequest for a new feature that's not currently supportedRequest for a new feature that's not currently supportedready for workEnough information for someone to start working onEnough information for someone to start working onv2Ideas, requests and plans for v2 of the SDK which will incorporate major changes and fixesIdeas, requests and plans for v2 of the SDK which will incorporate major changes and fixes
Milestone
Metadata
Metadata
Assignees
Labels
P1Significant bug affecting many users, highly requested featureSignificant bug affecting many users, highly requested featurebreaking changeWill break existing deployments when updated without changesWill break existing deployments when updated without changesenhancementRequest for a new feature that's not currently supportedRequest for a new feature that's not currently supportedready for workEnough information for someone to start working onEnough information for someone to start working onv2Ideas, requests and plans for v2 of the SDK which will incorporate major changes and fixesIdeas, requests and plans for v2 of the SDK which will incorporate major changes and fixes
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: