[Web-SIG] The write callable (vs. file-like object)
Phillip J. Eby
pje at telecommunity.com
Tue Aug 31 17:42:42 CEST 2004
At 10:07 PM 8/30/04 -0500, Ian Bicking wrote:
>Another comment I meant to make, but forgot about amid exceptions. The
>write callable is a bit awkward, because most code wants a file-like
>object, not a callable.
What other file-like properties do you want it to have?
Keep in mind that the average response should be sent by calling 'write()'
at most *once*, to write the entire page content, buffering the output of
some template. 'write()' imposes a potentially high synchronization cost
that reduces throughput if it's overused. It should *not* be used as the
target of output from any kind of page template. Application frameworks
should buffer template output (e.g. to a StringIO) and then either
'write()' or yield the result.
Multiple calls to 'write()' are for streaming output only, such as each
segment of a multipart server push, or for supporting frameworks that can't
work any other way. I guess I need to beef up the parts that say this.
The preferred mechanism for generating WSGI output is via the iterable
return value, as it allows the maximum concurrency and throughput for the
server. If we didn't need it for backward-compatibility with existing
frameworks, 'write()' and 'start_response()' simply wouldn't exist, and the
status and headers would be part of the return value as well.
>Like, the ability to write unicode; even if we leave it out now I don't
>see any good place where that could be added in the future, as the
>interface is rather minimal in that area. But my thinking is a little
>fuzzy in that area.
If Python currently had a "byte array" type, we'd be using that instead of
strings. Direct writing of Unicode isn't intended to ever be directly
supported by the standard, although in principle you could create some kind
of "encoding middleware" that sits directly atop the application. (An
application or framework written to it would technically not be
I guess I need to add something about byte arrays to the spec, especially
since Java/Jython may have this issue today (i.e. strings are Unicode, but
for HTTP a byte array is needed).
More information about the Web-SIG