I am trying to use io.TextIOWrapper to wrap a handle returned by urllib.request.urlopen. Reading line-by-line from the wrapped handle terminates prematurely.

As an example, consider this script:

import urllib.request
import io

url = "http://www.python.org"
handle = urllib.request.urlopen(url)
wrapped_handle = io.TextIOWrapper(handle, encoding='utf-8')
for line in wrapped_handle:
    pass

This gives:

Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ValueError: I/O operation on closed file.

This happens after 335 out of the 430 lines have been read (the last line read is "<p>The <a class="reference external" href="/psf/">Python Software Foundation</a> holds the intellectual property\n", which is line 335 on the www.python.org website.

Hum, io objects are not supposed to close themselves when they run out of data.
Even if HTTPResponse chooses to close the underlying socket (to clean unused resources?), it should not report itself as a closed io.IOBase.
Subsequent calls read() should return b"", this is the io.RawIOBase way to indicate EOF.

To fix this particular example, it seems enough to delete the "@property def closed(self)" from HTTPResponse. Note the XXX just above:
"""
    # XXX This class should probably be revised to act more like
    # the "raw stream" that BufferedReader expects.
"""
But close() should be modified as well, and internal calls to close() should be changed to only close the underlying socket.

This looks as a known bug in io.TextIOWrapper which call read() even previous read() returned an empty data. There was a related issue, I can't found it now.

buffer.read() never returns empty data in this case.

Indeed.

I have run into this bug myself.  Agree that a file-like object should never report itself as closed unless .close() has been explicitly called on it.   HTTPResponse should not return itself as closed after the end-of-file has been reached.

I think there is also a bug in the implementation of TextIOWrapper as well.  Even if the underlying file reports itself as closed, previously read and buffered data should be processed first before reporting an error about the file being closed.

Here is a patch which fixes HTTPResponse's end. "closed" property no longer settled automatically, but only after explicit close().

Senthil, Antoine, anyone, what you think about this patch?

This looks ok to me. I am slightly surprised that isclosed() isn't documented anywhere (but perhaps it's better).

New changeset 6cc5bbfcf04e by Serhiy Storchaka in branch '3.2':
Issue #16723: httplib.HTTPResponse no longer marked closed when the connection
http://hg.python.org/cpython/rev/6cc5bbfcf04e

New changeset 0461ed77ee4e by Serhiy Storchaka in branch '3.3':
Issue #16723: httplib.HTTPResponse no longer marked closed when the connection
http://hg.python.org/cpython/rev/0461ed77ee4e

New changeset 5f8c68281d18 by Serhiy Storchaka in branch 'default':
Issue #16723: httplib.HTTPResponse no longer marked closed when the connection
http://hg.python.org/cpython/rev/5f8c68281d18