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
Having generated model classes and method stubs is great but it should be optional.
Stubs are optional by design, they're only used by development tools. [no more stubs]
Once Lapidary validate models directly against the schema (#38) it should be possible to accept any model, e.q. a class instance, named tuple or plan dict. [not planning validation]
in case of class instances and perhaps named tuples, serialization to JSON might require consulting the openapi document to check for custom names (using x-lapidary-name).
Skipping support for dict would simplify the code, as it would require support for just a single interface (hasattr/getattr).
Response bodies could be returned as a simple named tuples, as they are fast, read-only and we don't use inheritance.
TODO: check if it's OK with mypy to have one type (class) in .pyi and another (NamedTuple) returned at run-time.
Using model types is convenience, but lapidary should support sending and receiving simple dictsin case of json content type.
The text was updated successfully, but these errors were encountered:
Having generated model classes and method stubs is great but it should be optional.
Stubs are optional by design, they're only used by development tools.[no more stubs]Once Lapidary validate models directly against the schema (#38) it should be possible to accept any model, e.q. a class instance, named tuple or plan dict.[not planning validation]in case of class instances and perhaps named tuples, serialization to JSON might require consulting the openapi document to check for custom names (using x-lapidary-name).Skipping support for dict would simplify the code, as it would require support for just a single interface (hasattr/getattr).
Response bodies could be returned as a simple named tuples, as they are fast, read-only and we don't use inheritance.TODO: check if it's OK with mypy to have one type (class) in .pyi and another (NamedTuple) returned at run-time.Using model types is convenience, but lapidary should support sending and receiving simple
dict
sin case of json content type.The text was updated successfully, but these errors were encountered: