feat: Support native inference parser for dataclass-like annotations. #141
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This is probably blocked on #117. Realistically, the currentannotation
andextra_annotations
used by the parsers is bad DX in comparison to something likeTypeView
. If all the parsers are going to end up refactored to be defined in terms of single-level value/annotation, it's going to make a lot more sense when the actual annotation bit is a TypeView instead.Result based of discussion from #137
The main problem with automatic dataclass-like inference, is that we can't know, without the annotation and an explicit decision from the user, whether a
list[T]
input is the appropriate input for the class itself, or if it wants the inputs to be splatted into the constructor.For anything where the single value would make sense today, it should already work.
As implemented, this is perhaps a decent amount more complicated because it's using theinvoke
machinery to apply allparse
operations now. It's not necessarily a problem, it's just a decent amount more code being evaluated for every parameter to introspect the function's parameter annotations before calling the function, versus just calling the function.It's now moderately more complicated at the collection phase, but not overly so, and the actual parse step is no more complicated. And
compose
can be handled with lists of parsers, which is the biggest simplification.