2 cents on file objects... WAS: RE: [Web-SIG] Bill's comments on WSGI draft 1.4

[Phillip J. Eby]

At 09:19 AM 9/2/04 -0400, Michael C. Neel wrote:
>Well, I've seen alot of back and forth on file objects, write(), etc.  I
>think it's of little issue myself, not that hard to return an interface
>that will support both methods.   Let the programming working on the
>middlware/application decide against the tradeoffs from one method to
>another.
>
>In the framework I use, I've actually altered it to allow it's context
>object (which is connected to the output stream, among other things) to
>be used as a file object.  The first need for this was to allow me to
>pass the object off to a cvs.writer object, when I then called with the
>result of a DB-API 2.0 fetchall(); and made a "Download as CSV" button
>work in no more than 4 lines of code.  I could also see doing this with
>XML classes for a WSDL/SOAP system.  Really off the wall, you could do
>this with the logging module, and send your logging statments to another
>server.
>
>I suppose with any of these I could grab the StringIO module and add a
>few extra lines to my code.  Then again, a WSGI system could also do
>that in it's implementation and ever offer me the options of buffered or
>non-buffered output.

Sorry, I've read through the above a few times and I haven't been able to 
figure out exactly what it is that you're proposing, or if you're proposing 
something at all.  :(


>As it's been said here before, adoption of the frameworks and server is
>going to be critical to WSGI.  So I'd opt for more choice and
>flexibility; we're all smart guys here and I don't think we would turn
>down a good idea because of complexity.

These sentences seem diametrically opposed to me; choice and flexibility is 
precisely what we *don't* want in WSGI, as it dramatically increases the 
opportunity for breaking interoperability.  Right now, it's still possible 
to write "dirt simple" implementations, because the requirements are 
minimal even though there are some options for improved performance.

There's a *big* difference between an option and a choice.  Choices double 
the work for everybody, while options only affect people who want to use 
them.  To the greatest extent possible, we should eliminate choices, and 
keep the number of options reasonable.  (For example, a few revisions ago, 
we dropped the "choice" of not returning an iterable.)