Open rafalkrupinski opened 1 month ago
Other than a theoretical, can you explain what use case this allows that's currently not possible?
Litestar will only ever provide parameters as concrete types, i.e. will always pass a list[str]
, never a Sequence[str]
, so I'm not sure what the benefit of allowing such annotations is, aside from catering to individual style preferences.
I'm asking because it is very much intentional to be restrictive about the typing, so as long as there's no functionality to be gained here, I'm wary of accepting such a feature request.
Currently Set, Sequence and possibly other types are accepted as parameter types, so it's unintuitive for me as a user, that litestar doesn'tt accept Iterable. The change is for ergonomics.
For example you don't want to do this. Even if it worked with litestar, it's a mutable default parameter value.
param: list[str] = []
This works but has different semantics and generates different OpenAPI schema, and you need to handle None value manually, and you need another variable or assert to please mypy.
param: list[str]|None=None
you can do
param: Sequence[str]=()
but currently this fails
param: Iterable[str]=()
It's unintuitive that one abstract type works and another doesn't.
Thanks for the explanation @rafalkrupinski, that seems reasonable!
Description
Litestar doesn't think it should process
Iterable
parameter as an array.The original discussion was about default parameter value, but the problem is actually with how litestar handles
Iterable
itselfURL to code causing the issue
https://github.com/litestar-org/litestar/blob/8c4c15bb501879dabaecfbf0af541ac571c08cf3/litestar/_kwargs/parameter_definition.py#L67C9-L67C60
MCVE
Steps to reproduce
Screenshots
No response
Logs
No response
Litestar Version
2.9.1
Platform