Demian Brecht added the comment: On 2015-01-29 9:51 PM, Martin Panter wrote: > The documentation currently says “Content-Length header should be explicitly > provided when the body is an iterable”. See Lib/urllib/request.py:1133 for > how it is done for urlopen(), using memoryview(), which is probabaly more > correct.
Sure, entirely disabling computing the content length if the body is an iterable is one way to address it, but I'm not convinced that it's better. If the ability is there to compute the content length, why not do so? The current implementation /should/ be correct whether elements are bytes or strings (the default encoding doesn't allow for multi-byte chars, so len(raw_string) should equal len(encoded_string)) when encoded using the new block of encoding code I added in the patch. Is there something that I'm missing? I could possibly see an argument for performance as you're iterating over each element in the list, but that would be entirely circumvented if the user defines the content length up front. ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue23350> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
