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.
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.