[Python-3000] Comment on iostack library

[Nick Coghlan]

Talin wrote:
> It seems to me that no matter how you slice it, you can't have an 
> abstract "buffering" layer that is independent of both the layer beneath 
> and the layer above. Both the text decoding layer and the disk i/o layer 
> need to have fairly intimate knowledge of their buffers if you want 
> maximum efficiency. (I'm not opposed to a custom implementation of 
> buffering in the level 1 file object itself, although I suspect in most 
> cases you'd be better off using what the OS or its standard libs provide.)

You'd insert a buffering layer at the appropriate point for whatever you're 
trying to do. The advantage of pulling the buffering out into a separate layer 
is that it can be reused with different byte sources & sinks by supplying the 
appropriate configuration parameters, instead of having to reimplement it for 
each different source/sink.

Applications generally won't be expected to construct these IO stacks 
manually. File IO stacks, for example, will most likely still be created by a 
call to the open() builtin (although the default mode may change to be binary 
if no text encoding is specified).

Here's a list of the IO stacks I believe will be commonly used:

Unbuffered byte IO stack:
   - byte stream API
   - byte source/sink

Block buffered byte IO stack:
   - byte stream API
   - block buffering layer
   - byte source/sink

Character buffered text IO stack:
   - text stream API
   - text codec layer
   - byte source/sink
(effectively unbuffered for single byte encodings like ASCII)

Block buffered text IO stack:
   - text stream API
   - text codec layer
   - block buffering
   - byte source/sink

Line buffered text IO stack:
   - text stream API
   - line buffering
   - text codec layer
   - block buffering
   - byte source/sink

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia
---------------------------------------------------------------
             http://www.boredomandlaziness.org