In Python2 Popen uses *FILE objects, which wind up buffering even though
subprocess defaults to no buffering. In Python3, subprocess streams really
are unbuffered by default, but the imaplib code assumes read is buffered. This
patch uses the default buffer size from the io module to get buffered streams
from Popen.
Much debugging work and patch by Diane Trout.
The imap protocol is too complicated to write a test for this simple
change with our current level of test infrastructure.
In Python2 Popen uses *FILE objects, which wind up buffering even though
subprocess defaults to no buffering. In Python3, subprocess streams really
are unbuffered by default, but the imaplib code assumes read is buffered. This
patch uses the default buffer size from the io module to get buffered streams
from Popen.
Much debugging work and patch by Diane Trout.
The imap protocol is too complicated to write a test for this simple
change with our current level of test infrastructure.
This fixes a regression relative to Python2. (In 2, methods on a class were
unbound methods and matched the inspect queries being done, in 3 they are just
functions and so were missed).
This is an undocumented function that pydoc itself does not use, but
I found that numpy at least uses it in its documentation generator.
Original patch by Matt Bachmann.
This fixes a regression relative to Python2. (In 2, methods on a class were
unbound methods and matched the inspect queries being done, in 3 they are just
functions and so were missed).
This is an undocumented function that pydoc itself does not use, but
I found that numpy at least uses it in its documentation generator.
Original patch by Matt Bachmann.
Previously the parts of the message retained whatever linesep they had on
read, which means if the messages weren't read in univeral newline mode, the
line endings could well be inconsistent. In general sending it via smtplib
would result in them getting fixed, but it is better to generate them
correctly to begin with. Also, the new send_message method of smtplib does
not do the fixup, so that method is producing rfc-invalid output without this
fix.
Previously the parts of the message retained whatever linesep they had on
read, which means if the messages weren't read in univeral newline mode, the
line endings could well be inconsistent. In general sending it via smtplib
would result in them getting fixed, but it is better to generate them
correctly to begin with. Also, the new send_message method of smtplib does
not do the fixup, so that method is producing rfc-invalid output without this
fix.
