Gregory P. Smith added the comment:
that patch looks good for imaplib.
i'll follow up on the subprocess side of things to see if the default
behavior should be changed to better match what happened in 2.7 (or if not:
to make sure the change in behavior is sufficiently documented and not
relied
Roundup Robot added the comment:
New changeset c5aacf9d1cdc by R David Murray in branch '3.2':
#17443: Fix buffering in IMAP4_stream.
http://hg.python.org/cpython/rev/c5aacf9d1cdc
New changeset 0baa65b3ef76 by R David Murray in branch '3.3':
Merge: #17443: Fix buffering in IMAP4_stream.
R. David Murray added the comment:
Thanks, Diane, and expecially thanks for finding this and helping is track down
the cause.
We need better test infrastructure for imap...because this occurs only during
string litteral reads, I decided that making a test for this with our current
imap test
Diane Trout added the comment:
After bumping into r.david.murray in the elevator I got the impression setting
the bufsize argument to the Popen call would be a better idea.
I found that BufferedReader/Writer were using a DEFAULT_BUFFER_SIZE set
somewhere in the c part of io. To cut down on
Antoine Pitrou added the comment:
os.fdopen() in 2.x would always create a FILE*, and therefore inherit fread()'s
semantics even in unbuffered mode. In 3.x, unbuffered I/O instead calls
read() directly, and happily returns partial reads; this is by design.
So, I guess imaplib should be fixed
Antoine Pitrou added the comment:
I don't think there's any reason to open the subprocess in unbuffered mode (you
aren't sharing the stdio streams with anyone else). Just be careful to call
flush() on stdin before attempting to read any response from stdout.
--
Gregory P. Smith added the comment:
Yes imaplib can be fixed pretty easily and should use buffered IO regardless.
I'm pondering if the default behavior of subprocess needs fixing as
existing python 2.x code being ported to 3 doesn't expect this changed
behavior of the PIPE file objects. It
Diane Trout added the comment:
So as a first stab at fixing this. I modified imaplib to wrap the process.stdin
/ process.stdout from with io.BufferedWriter / io.BufferedReader. I didn't use
the TextIOWrapper as the imaplib wanted to work with the raw \r\n.
The change seems to have fixed the
Changes by Gregory P. Smith g...@krypto.org:
--
nosy: gregory.p.smith
priority: normal
severity: normal
status: open
title: imaplib.IMAP4_stream subprocess is opened unbuffered but ignores short
reads
___
Python tracker rep...@bugs.python.org
New submission from Gregory P. Smith:
imaplib.IMAP4_stream subprocess is opened unbuffered but ignores short reads
when reading the message body. Depending on timing, message body size and
kernel pipe buffer size and phase of the moon and whether you're debugging the
thing or not... It can
Gregory P. Smith added the comment:
The error does not happen when running the same code under 2.7, despite the
same default bufsize=0 subprocess behavior. This is likely due to differences
in the Python 2.x old style io library when os.fdopen(fd, 'rb', bufsize) is
used vs 3.x when
Changes by Diane Trout di...@ghic.org:
--
nosy: +detrout
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue17443
___
___
Python-bugs-list mailing list
12 matches
Mail list logo