-
Notifications
You must be signed in to change notification settings - Fork 0
Description
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.