Change by Rishi :
--
nosy: +rishi93
___
Python tracker
<https://bugs.python.org/issue39017>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.pyth
Rishi added the comment:
Hi ! I would like to start contributing to CPython. Can I start working on this
issue ?
--
___
Python tracker
<https://bugs.python.org/issue39
Change by Rishi :
--
keywords: +patch
pull_requests: +20602
stage: test needed -> patch review
pull_request: https://github.com/python/cpython/pull/21454
___
Python tracker
<https://bugs.python.org/issu
Rishi added the comment:
Thank you. I have signed the CLA agreement. I have pushed my code changes and
also written a testcase for this issue
--
___
Python tracker
<https://bugs.python.org/issue39
Rishi added the comment:
Hello all,
Could I help by adding this to the documentation ?
--
nosy: +rishi93
___
Python tracker
<https://bugs.python.org/issue41
Rishi added the comment:
Here is my attempt to fix this issue. This is my first patch ever :).
IMO checking socket leaks in the constructor requires an actual server, so I
create an actual localhost dummy server and test some error conditions that are
encountered by the constructor
Rishi added the comment:
patch updated to use just plain exception
--
Added file: http://bugs.python.org/file36819/issue22351_1.patch
___
Python tracker
<http://bugs.python.org/issue22
Rishi added the comment:
patch updated based on comments.
--
Added file: http://bugs.python.org/file36873/issue22351_2.patch
___
Python tracker
<http://bugs.python.org/issue22
Rishi added the comment:
My observation is that a file with more than normal (exact numbers below)
line-feed characters takes way too long.
I tried porting the above patch to my default branch, but it has some boundary
and CRLF/LF issues, but more importantly it relies on seeking the file
Rishi added the comment:
Antoine, I will upload a patch that relies on BufferedReader. As you mentioned,
it will get rid of supporting the buffer and reduce a lot of code.
The only issue is that it helps me to know if the current buffer is at EOF (the
documentation of peek does not mention
Rishi added the comment:
I have recreated the patch(issue1610654_1.patch) and it performs more or less
like the earlier patch
Serhiy,
I agree we cannot use handmade buffering here, without seeking ahead.
I believe, we can make optimizations for streams which are buffered and
non-seekable.
Cgi
Rishi added the comment:
Patch updated from review comments. Also added a few corner test cases.
--
Added file: http://bugs.python.org/file37128/issue1610654_2.patch
___
Python tracker
<http://bugs.python.org/issue1610
Rishi added the comment:
Hi,
I have created a new patch with a small design change. The change is that in
situations where I don't find the boundary instead of keeping the last x bytes
in the buffer I simply drain the whole data and call a readline().
This seems like the right thing
Rishi added the comment:
There is indeed a test failure that occurs without the patch. This is a new
test I had added.
The reason is that in the existing implementation, when a boundary does not
exist, the implementation does not include the trailing CRLF, LF or for that
matter CR as part of
Rishi added the comment:
One of my comments shot the wrapped line limit. Also changed the test in
question to check the lengths of the expected and actual buffer to checking the
contents of the respective buffers.
--
Added file: http://bugs.python.org/file37400/issue1610654_5.patch
15 matches
Mail list logo
