This PR adds basic documentation for the decode_unicode parameter to iter_content (and implicitly for iter_lines). It also ensures the now-documented behavior is correct and consistent, specifically by honoring the parameter in all cases and not just in some (previously only apparent by reading the source).
Add documentation about decode_unicode.
Always honor decode_unicode, even when _content is present.
extra : amend_source : 25977a1227b163d49bf2e1aec6aa448e5cd3be8a
Thanks for this!
In general this fix looks great, thanks! Would you mind providing a test? One that confirms that you get back unicode in the cases in question would be good enough.
Add tests for decode_unicode
Call me crazy but this would look better if it were simply:
chunks = iter_slices(self._content, chunk_size)
chunks = generate()
Ternaries are not used in the requests code base and are generally advised against by PEP8 (one of the few places requests' style and PEP8 happen to coincide). You're also unconditionally creating two iterators which incurs the cost of creation and garbage collection (which has two parts: decrementing the ref count and collecting the object on the next sweep of the garbage collector) as opposed to creating one iterator (and binding) and returning it.
You're welcome to adjust the style to suit the projects' preferences. I prefer ternary statements for assignment because it communicates better:
I did recognize the unconditional construction of the two iterators, but I considered the costs to be negligible. In general, I would only consider costs of function calls and object construction/destruction in highly sensitive tight loops. Perhaps this method falls into that category for some applications, but I suspect not as it's likely to be I/O bound instead. That said, if you wanted to keep the ternary operator but not have the unconditional construction, you could easily:
chunks = iter_slices(self._content, chunk_size) if self._content_consumed else generate()
I chose to create variables in an attempt to create more self-documenting code. Giving names to reused_chunks and stream_chunks adds clarity to the behavior. I believe the clarity of purpose outweighs the performance costs of unconditional construction.
But again, please feel free to accept my contribution as is and then tweak it to suit your preferences.
✨ 🍰 ✨