-
Notifications
You must be signed in to change notification settings - Fork 404
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Incorrect type annotation for parse function #802
Comments
Thanks for opening your first issue here! We'll come back to you as soon as we can. |
Thanks a lot @DanLipsitt for flagging it. I confess this has been a flaky area in Parser - we had generics and it half-worked - perhaps an @overload specifically when envelope is set might work. |
Looking into this now to see if a quick fix I have in mind can solve, otherwise we'll tackle it for the release after next. Thanks a lot for the sample to reproduce as it helps a ton! |
@DanLipsitt got it working - Could you please check this PR to double check this is what you'd expect? If you can confirm by EOD we can make it into the next release, otherwise, I'll pause this for a while as everything I've tried didn't work (Unions, TypeVar + Type variables, etc.) Thank you! |
Now released as part of 1.23 version |
The output type specified for
aws_lambda_powertools.utilities.parser.parse
does not always match the documented or actual output. The output is often a collection but the specified type is a single object.Expected Behavior
The return type for
parse
should match the documented output types for each envelope.Current Behavior
The return type for
parse
isModel
(the type of themodel
parameter's input) even though the returned value may be a collection with a more complex type such asList[Dict[str, Optional[Model]]]
.Possible Solution
There may be a way to solve this using mypy generics but I can't think of how. The return type could be specified manually as something like the following
Union
of all the possibilities:This would have to be updated as envelopes are added, and it wouldn't cover custom envelopes.
Alternatively, removing the output type annotation from the toplevel
parse
might allow the type of the underlying envelope'sparse
function to bubble up.Steps to Reproduce
Output:
Mypy output:
Environment
1.21.1
Pypi
n/a
n/a
The text was updated successfully, but these errors were encountered: