-
-
Notifications
You must be signed in to change notification settings - Fork 2k
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
Implemented readuntil in StreamResponse #4734
Conversation
I need to check if documentation work is needed or if it is automatic, meanwhile if somebody can clear my mind about this before I check it is welcome |
not_enough = True | ||
|
||
while not_enough: | ||
while self._buffer and not_enough: | ||
offset = self._buffer_offset | ||
ichar = self._buffer[0].find(b'\n', offset) + 1 | ||
# Read from current offset to found b'\n' or to the end. | ||
ichar = self._buffer[0].find(separator, offset) + 1 |
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.
asyncio has much more effective solution. Why not to copy-paste it ?
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 did not want to change much the code.
What do you think should be copied from asyncio implementation?
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 think sync the implementation with asyncio would be great!
asyncio doesn't incrementally copy data to the buffer in a loop but calculates boundaries and move bytes once.
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.
Okay, I will fix it
Codecov Report
@@ Coverage Diff @@
## master #4734 +/- ##
==========================================
- Coverage 97.56% 97.54% -0.03%
==========================================
Files 43 43
Lines 8779 8784 +5
Branches 1412 1413 +1
==========================================
+ Hits 8565 8568 +3
- Misses 100 101 +1
- Partials 114 115 +1
Flags with carried forward coverage won't be shown. Click here to find out more.
Continue to review full report at Codecov.
|
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 can live with not the-fast-possible implementation but the documentation update is required for merging.
Please update docs/streams.rst
Yes, okay, this weekend I will have some time to fix it |
37e4f2d
to
d483e2f
Compare
Hello, I tried to mimic more the asyncio implementation but it appears to me that it is quite difficult task and a lot of code will be changed. Simply copying the data from I added the docs by the way. |
@asvetlov do you think the StreamReader could be written in a better and more performant way inheriting StreamReader from asyncio? |
Thanks for the patience! |
Co-authored-by: Andrew Svetlov <[email protected]>
💚 Backport successfulThe PR was backported to the following branches:
|
Co-authored-by: Andrew Svetlov <[email protected]> Co-authored-by: Anas <[email protected]> Co-authored-by: Andrew Svetlov <[email protected]>
Co-authored-by: Andrew Svetlov <[email protected]>
Co-authored-by: Andrew Svetlov <[email protected]>
What do these changes do?
Added
readuntil
method, heavily mimickingasyncio.streams
and recycling the code of readline in currentStreamResponse
class. With this changereadline
usesreaduntil
with\n
as a separatorSame for the tests that just use different separators.
Are there changes in behavior for the user?
New way to wait for new data
Related issue number
#4054
Checklist
CONTRIBUTORS.txt
This change is inside another PR I submitted AioHTTPTestCase more async friendly #4732CHANGES
folder<issue_id>.<type>
for example (588.bugfix)issue_id
change it to the pr id after creating the pr.feature
: Signifying a new feature..bugfix
: Signifying a bug fix..doc
: Signifying a documentation improvement..removal
: Signifying a deprecation or removal of public API..misc
: A ticket has been closed, but it is not of interest to users.