On Thu, Jan 7, 2016, at 06:53, Chris Angelico wrote:
On Thu, Jan 7, 2016 at 10:37 PM, Paul Moore
wrote: So IMO, this needs to be addressed as a documentation (and possibly code) fix in requests. It's something of a shame that httplib.client doesn't reject Unicode strings rather than making a silent assumption of the encoding, but that's something we have to live with for backward compatibility reasons. But there's no reason requests has to expose that behaviour to the user.
Personally, I would be happy with any of three behaviours:
1) Raise TypeError and demand that byte strings be used 2) Encode as UTF-8, since that's most likely to "just work", and is also consistent 3) Encode as ASCII, and let any errors bubble up.
What about: 4) Silently add a content type (default text/plain; charset=UTF-8) or charset (if the user has specified a content type without one) if a unicode string is used. If a byte string is used, use application/octet-stream for the default content type and don't add a charset in any case (even if the user-specified content type is text/*)