This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author martin.panter
Recipients Anthony.Kong, LorenzMende, ajaksu2, dheiberg, ggenellina, jjlee, kc, martin.panter, matejcik, orsenthil
Date 2019-02-16.07:13:23
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1550301204.07.0.981227468533.issue5038@roundup.psfhosted.org>
In-reply-to
Content
For 3.7+ (where iterable objects are supported), I suggest:

1. Document the problem as a limitation of handlers like AbstractBasicAuthHandler, and consider raising an exception instead of trying to upload a file or iterable a second time.

2. Clarify the behaviour for different types of the “urllib.request” data parameter. I understand “file-like objects” means objects with a “read” attribute, and the “read” method is called in preference to iteration or treating the parameter as a “bytes” object.

Despite the bug title, I don’t think the library should mess with the file position. Certainly not when making a single request. But it should already be possible for the caller to supply a custom iterable object that resets the file position:

class FileReiterator:
    def __iter__(self):
        self.file.seek(0)
        while True:
            chunk = self.file.read(self.chunksize)
            yield chunk
            if len(chunk) < self.chunksize:
                break
History
Date User Action Args
2019-02-16 07:13:24martin.pantersetrecipients: + martin.panter, jjlee, ggenellina, orsenthil, ajaksu2, matejcik, Anthony.Kong, LorenzMende, dheiberg, kc
2019-02-16 07:13:24martin.pantersetmessageid: <1550301204.07.0.981227468533.issue5038@roundup.psfhosted.org>
2019-02-16 07:13:24martin.panterlinkissue5038 messages
2019-02-16 07:13:23martin.pantercreate