[Python-3000] iostack and sock2

[Josiah Carlson]

Nick Coghlan <ncoghlan at gmail.com> wrote:
[snip]
> Any operations that may touch the filesystem or network shouldn't be 
> properties - attribute access should never raise IOError (this is a guideline 
> that came out of the Path discussion). (e.g. the 'position' property is 
> probably a bad idea, because x.position may then raise an IOError)

I agree completely.

> The stream layer hierarchy needs to be limited to layers that both expose and 
> use the normal bytes-based Stream API. A separate stream interface concept is 
> needed for something that can be used by the application, but cannot have 
> other layers stacked on top of it. Additionally, any "bytes-in-bytes-out" 
> transformation operation can be handled as a single codec layer that accepts 
> an encoding function and a decoding function. This can then be used for 
> compression layers, encryption layers, Golay encoding, A-law companding, AV 
> codecs, etc. . .
> 
>    StreamLayer
>      * ForwardingLayer - forwards all data written or read to another stream
>      * BufferingLayer - buffers data using given buffer size
>      * CodecLayer - encodes data written, decodes data read
> 
>    StreamInterface
>      * TextInterface - text oriented interface to a stream
>      * BytesInterface - byte oriented interface to a stream
>      * RecordInterface - record (struct) oriented interface to a stream
>      * ObjectInterface - object (pickle) oriented interface to a stream

I think these are generally OK.

[snip]

As I've been reading the updated IO stack discussions since Tomer
brought it up months ago, I've been generally -1 on the idea of
rewriting the IO stack.  I didn't know why at first, but I've figured
out that it is a combination of "I enjoy writing wire protocols" and "it
would be very nice if my old socket/file software continued to work in
py3k".

Obviously the first part will generally not be an issue (and wouldn't
be sufficiently compelling to refuse the change) with the updated IO
stack, but the second will be. That is, if we switched from the current
IO methods to the stack, all old socket and file handling software seem
as though they will break.  This sounds to me like gratuitous breakage.

On the other hand, I wouldn't mind a new IO stack module or package that
defined wrappers and such for files, sockets, etc., along with the
StreamLayer and StreamInterface bits somewhere.

One could then add an interface to the previously mentioned module for
asynchronous IO on *nix (I can't remember its name), with a (hopefully)
updated implementation for Windows, falling back to an implementation
that uses select on platforms where an updated method is not available. 
Whether or not we would want to make this updated select-like framework
available to old sockets, files, etc., is a separate discussion.

 - Josiah