You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
At the moment, the intention is that a DirectThingClient and a ThingClient should have the same signature, but in reality the server-side "client" object returns Pydantic models (if that's the return type) while the client-side version returns simple Python objects (i.e. whatever's deserialised from JSON).
Once code generation is in (#89) we might be able to return Model objects from both. That would make everything so much neater and more type-checkable. Handling un-annotated types gracefully might be a challenge, but hopefully one we can figure out.
The text was updated successfully, but these errors were encountered:
Related to this: it would be very nice to handle Blob types better - i.e. automatically inflate them to blob objects from the dictionary. This is much easier if we have the blob in a response model. I'd envisage registering Blob subclasses for specific mime types, and picking the best class for each blob. That way, JPEGBlobs could be easily turned back into images, for example.
At the moment, the intention is that a
DirectThingClient
and aThingClient
should have the same signature, but in reality the server-side "client" object returns Pydantic models (if that's the return type) while the client-side version returns simple Python objects (i.e. whatever's deserialised from JSON).Once code generation is in (#89) we might be able to return Model objects from both. That would make everything so much neater and more type-checkable. Handling un-annotated types gracefully might be a challenge, but hopefully one we can figure out.
The text was updated successfully, but these errors were encountered: