[issue41104] IMAPlib debug errors
New submission from skorpeo : This line in imaplib.py inside _dump_ur function: l = map(lambda x:'%s: "%s"' % (x[0], x[1][0] and '" "'.join(x[1]) or ''), l) fails because the untagged responses are bytestrings and it expects regular strings. -- components: Library (Lib) messages: 372252 nosy: skorpeo priority: normal severity: normal status: open title: IMAPlib debug errors type: behavior versions: Python 3.5, Python 3.6, Python 3.7, Python 3.8, Python 3.9 ___ Python tracker <https://bugs.python.org/issue41104> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35649] http.client doesn't close. Infinite loop
New submission from skorpeo : when testing example from https://docs.python.org/3/library/http.client.html. Specifically the chunked example, i.e. while not r1.closed. Results in infinite loop. I believe this is because line 398 function def _close_conn(self), should call self.close(). -- messages: 332934 nosy: skorpeo priority: normal severity: normal status: open title: http.client doesn't close. Infinite loop versions: Python 3.5, Python 3.6, Python 3.7 ___ Python tracker <https://bugs.python.org/issue35649> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35649] http.client doesn't close. Infinite loop
Change by skorpeo : -- type: -> behavior ___ Python tracker <https://bugs.python.org/issue35649> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35649] http.client doesn't close. Infinite loop
skorpeo added the comment: Ha, ok that would explain it. Yes, I think it would indeed be helpful to update the example, but then again I guess leaving it as is may be a good way to find out if people are reading the docs. On Thu, Jan 3, 2019 at 10:21 PM Martin Panter wrote: > > Martin Panter added the comment: > > This was changed in Python 3.2+ in Issue 16723. The response object no > longer sets the “closed” attribute when it runs out of data; it is only set > when the “close” method is called. Perhaps the example should be amended so > that it checks if “read” returned an empty string, rather than checking > “closed”. > > Another problem with the example is that printing the chunk as a bytes > object can trigger BytesWarning. I would add a “repr” call to avoid that. > > -- > assignee: -> docs@python > components: +Documentation > nosy: +docs@python, martin.panter > > ___ > Python tracker > <https://bugs.python.org/issue35649> > ___ > -- title: http.client doesn't close. Infinite loop -> http.client doesn't close. Infinite loop ___ Python tracker <https://bugs.python.org/issue35649> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33662] asyncio Stream Reader Blocks on read when data fetched is less than limit
New submission from skorpeo : I humbly submit what I think may be a bug in the asyncio.StreamReader.read() function. When n=-1 is supplied and the data is less than self._limit the read function creates a future and never wakes it up. I believe the culprit is https://github.com/python/cpython/blob/9d3627e311211a1b4abcda29c36fe4afe2c46532/Lib/asyncio/streams.py#L632. To fix the issue a condition is added to break out of the loop if the data read is less than the limit. I can only attach one file so I am providing the fix here for asyncio streams.py: blocks.append(block) # existing if len(block) < self._limit: # new break # new I have also attached a test file that shows the blocking behavior which is alleviated with the above fix. Finally, I am not sure how to handle a situation where the data is exactly equal to the limit and no subsequent data is sent. -- components: asyncio files: pty_test.py messages: 317810 nosy: asvetlov, skorpeo, yselivanov priority: normal severity: normal status: open title: asyncio Stream Reader Blocks on read when data fetched is less than limit type: behavior versions: Python 3.6 Added file: https://bugs.python.org/file47615/pty_test.py ___ Python tracker <https://bugs.python.org/issue33662> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33662] asyncio Stream Reader Blocks on read when data fetched is less than limit
skorpeo added the comment: Yes makes sense, it could be another bug with TTY or just my error and I did preface that I am submitting this humbly. You are also correct that there is no clean up for closing the pipes. On Mon, May 28, 2018 at 1:45 AM, Yury Selivanov wrote: > > Yury Selivanov added the comment: > > "if not block:" means EOF and replacing it with "if len(block) < > self._limit:" would break everything. > > There might be another bug here (with TTY) or, maybe, there's a bug in > pty_test.py. For example, I don't see how you closing reader_pipe or > writer_pipe. > > -- > > ___ > Python tracker > <https://bugs.python.org/issue33662> > ___ > -- ___ Python tracker <https://bugs.python.org/issue33662> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33662] asyncio Stream Reader Blocks on read when data fetched is less than limit
skorpeo added the comment: yes, in this case they were meant to stay open to write and read multiple messages. I was hoping to read data when it is available, the other work around was to specify n, but that also blocked once there was no more data to be fetchedEither way I will stick to queues and this appears to be expected behavior so you can disregard the report. I should have known better that I wasn't going to find a bug in python :) On Mon, May 28, 2018 at 2:03 AM, Yury Selivanov wrote: > > Yury Selivanov added the comment: > > > You are also correct that there is no clean up for closing the pipes. > > It's not just about the cleanup. If you don't close the pipes, they will > be open forever, so there will be no EOF for which read(-1) will wait > forever. > > -- > > ___ > Python tracker > <https://bugs.python.org/issue33662> > ___ > -- ___ Python tracker <https://bugs.python.org/issue33662> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
