minor grammar and syntax fixes #148
Conversation
|
|
||
| Waitress will set a ``Content-Length`` header on the behalf of an application | ||
| when a file wrapper with a sufficiently filelike object is used if the | ||
| when a file wrapper with a sufficient ``filelike_object`` is used if the |
There was a problem hiding this comment.
Why did you change it to filelike_object? That's not correct here.
There was a problem hiding this comment.
I thought it was a typo. I'll change it to "sufficiently file-like object".
| application hasn't already set one. | ||
|
|
||
| The machinery which handles a file wrapper currently doesn't do anything | ||
| particularly special using fancy system calls (it doesn't use ``sendfile`` | ||
| for example); using it currently just prevents the system from needing to | ||
| copy data to a temporary buffer in order to send it to the client. No | ||
| copying of data is done when a WSGI app returns a file wrapper that wraps a | ||
| sufficiently filelike object. It may do something fancier in the future. | ||
| sufficient ``filelike_object``. It may do something fancier in the future. |
There was a problem hiding this comment.
filelike object here is a general term to describe an object that is file like, filelike_object refers to a single instance of said object.
"wraps a sufficient filelike_object" is wrong, because we are not wrapping a filelike_object, we are wrapping an object that happens to behave and look like a Python file.
| filelike object using the provided block_size is used (and copying is done, | ||
| negating any benefit of the file wrapper). It *should* support a ``close()`` | ||
| method. | ||
| ``filelike_object`` using the provided ``block_size`` is used (and copying is |
There was a problem hiding this comment.
It's fine to keep this filelike_object
There was a problem hiding this comment.
"filelike object" is wrong. It should be either "file-like object" when used in plain old English or "filelike_object" when referring to programming language.
In this instance, the latter is seems more contextually appropriate to me, since it aligns with block_size
No description provided.