-
-
Notifications
You must be signed in to change notification settings - Fork 198
Create common interface for aio response classes #1328
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
Conversation
Having the `parse` method async on all parsers means the need for checking that `parse` is a coroutine is not needed anymore. The check for coroutine or not moved into the parser where a private method can be async or sync. This cleans up the public interface of the aio response classes.
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## master #1328 +/- ##
==========================================
- Coverage 90.79% 90.79% -0.01%
==========================================
Files 68 68
Lines 6553 6548 -5
==========================================
- Hits 5950 5945 -5
Misses 603 603
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as resolved.
Looks good to me! Would you mind adding an entry to CHANGES.rst? |
How does
sound for a changelog entry? It communicates a change and where it is, though doesn't say what the implications are for aiobotocore users. Is |
This comment was marked as resolved.
This comment was marked as resolved.
aiobotocore/endpoint.py
Outdated
parsed_response = await parser.parse( | ||
response_dict, operation_model.output_shape | ||
) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
have we validated across all the parsers this is now true? Are there parsers that don't inherit from our baseclass?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
i see everything parents to ResponseParser 👍🏼
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good call!
Upstream has a number of parsers that we have not patched:
BaseXMLResponseParser
BaseJSONParser
BaseEventStreamParser
EventStreamJSONParser
EventStreamXMLParser
BaseRestParser
The Base*
parsers should be fine, since we patch any relevant child parsers. But I believe the EventStream*
parsers might be problematic. They are used indirectly and might need to be patched to work correctly.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I could prepare a follow-up of #1312 to fully patch the parser class hierarchy. That would be a prerequisite for this PR, IMO. Any thoughts?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
#1329 makes sure that EVENT_STREAM_PARSER_CLS
class attributes ("indirect" uses) point to patched parsers. Once that is merged, we can continue with this one.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
My belief atm is that not having an async version for
EventStream*
is fine.
I guess it would be, as long as we continue to allow for both sync and async variants of parse()
. However, this PR takes away that flexibility and we need to be careful to handle all parser classes, as @thehesiod rightfully pointed out. As far as I understand, that includes parser classes that we have not patched previously, hence #1329. I could well be on the wrong track here, though.
An alternative would be to simply keep the current implementation of parse()
and move it up the AioResponseParser
, but leave everything else as it is.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ya that's why I was waiting to do a review of this PR when I had some time, we need to thoroughly look at how these classes are used
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
lets report back when one of us does that
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
How about allowing sync parse
methods but emit a deprecation warning?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
sounds like a plan, would be safer
CHANGES.rst
Outdated
@@ -5,6 +5,7 @@ Changes | |||
^^^^^^^^^^^^^^^^^^^ | |||
* patch `ResponseParser` | |||
* use SPDX license identifier for project metadata | |||
* refactor `AioResponseParser` to have a consistent async implementation of the `parse` method. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's RST
* refactor `AioResponseParser` to have a consistent async implementation of the `parse` method. | |
* refactor ``AioResponseParser`` to have a consistent async implementation of the ``parse`` method. |
To avoid a breaking change the callers of a ResponseParser.parse method yield a deprecation warning when a non-async method is found.
parsed_response = parser.parse( | ||
response_dict, operation_model.output_shape | ||
warnings.deprecated( | ||
f"The use of non-async `parse` function on {parser.__class__.__name__} is deprecated." |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why not use type(parser).__name__
?
) | ||
else: | ||
parsed = parser.parse(response_dict, operation_model.output_shape) | ||
parsed = await parser.parse(response_dict, operation_model.output_shape) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Apply deprecation pattern from endpoints.py
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That test was slightly refactored in the default branch. Please do a rebase or merge in new commits.
Superseded by #1347 |
Having the
parse
method async on all parsers means the need for checking thatparse
is a coroutine is not needed anymore. The check for coroutine or not moved into the parser where a private method can be async or sync. This cleans up the public interface of the aio response classes.Description of Change
Change is extracted out of pull #1323 after a review comment ask for it.
Assumptions
Replace this text with any assumptions made (if any)
Checklist for All Submissions
Checklist when updating botocore and/or aiohttp versions