[Web-SIG] The write callable (vs. file-like object)

[Phillip J. Eby]

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 
WSGI-compliant.)

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).