Author martin.panter
Recipients Rotkraut, demian.brecht, harobed, martin.panter, orsenthil, petri.lehtinen, piotr.dobrogost, pitrou, whitemice
Date 2015-04-01.04:27:07
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1427862428.33.0.815935430633.issue12319@psf.upfronthosting.co.za>
In-reply-to
Content
Perhaps you should make a table of some potential body object types, and figure out what the behaviour should be for request() with and without relevant headers, and endheaders() and send() with and without encode_chunked=True:

* Add/don’t add Content-Length/Transfer-Encoding
* Send with/without chunked encoding
* Raise exception
* Not supported or undefined behaviour

Potential body types:

* None with GET/POST request
* bytes()
* Latin-1/non Latin-1 str()
* BytesIO/StringIO
* Ordinary binary/Latin-1/other file object
* File object reading a special file like a pipe (st_size == 0)
* File object wrapping a pipe or similar that does not support fileno() (ESPIPE)
* Custom file object not supporting fileno() nor seeking
* File object at non-zero offset
* GzipFile object, where fileno() corresponds to the compressed size
* GzipFile not supporting fileno(), where seeking is possible but expensive
* Iterator yielding bytes() and/or strings
* Generator
* File object considered as an iterable of lines
* List/tuple of bytes/text
* Other sequences of bytes/text
* Other iterables of bytes/text, e.g. set(), OrderedDict.values()

This list could go on and on. I would rather have a couple of simple rules, or explicit APIs for the various modes so you don’t have to guess which mode your particular body type will trigger.
History
Date User Action Args
2015-04-01 04:27:08martin.pantersetrecipients: + martin.panter, orsenthil, pitrou, harobed, petri.lehtinen, piotr.dobrogost, demian.brecht, whitemice, Rotkraut
2015-04-01 04:27:08martin.pantersetmessageid: <1427862428.33.0.815935430633.issue12319@psf.upfronthosting.co.za>
2015-04-01 04:27:08martin.panterlinkissue12319 messages
2015-04-01 04:27:07martin.pantercreate