[Python-3000] new io (pep 3116)

[tomer filiba]

On 5/7/07, Guido van Rossum <guido at python.org> wrote:
> That's not symmetric. readline() returns a string that includes a
> trailing \n even if the actual file contained \r or \r\n. write()
> already is supposed to translate \n anywhere (not just at the end of
> the line) into the specified or platform-default (os.sep) separator.

well, if write() is meant to do that anyway, writeline() is not required.

> > moreover, the current socket interface simply mimics the BSD
> > interface. setsockopt, getsockopt, et al, are very unpythonic by nature --
> > the ought to be exposed as properties or methods of the socket.
> > all in all, the current socket model is very low level with no high
> > level design.
>
> That's all out of scope for the PEP. Also I happen to think that
> there's nothing particularly wrong with sockets -- they generally get
> wrapped in higher layers like httplib.

first, when i first brought this up a year ago, you were in favor
http://mail.python.org/pipermail/python-3000/2006-April/001497.html

still, there's much code that handles sockets. the client side is
mostly standard: connect, do something, quit. but on the server side
it's another story, and i have had many long battles with man pages
to make sockets behave as expected. not all protocols are based
on http, after all, and the fellas that write modules like httplib have
a lot of black magic to do.

a better design of the socket module could help a lot, as well as
making small, repeated tasks easier/more logical. compare
    import socket
    s = socket.socket()
    s.connect(("foobar", 1234))
to
    from socket import TcpStream
    s = TcpStream("foobar", 1234)

> > you can see it here -- http://sebulba.wikispaces.com/project+sock2
> > i know it's late already, but i can write a PEP over the weekend,
> > or if someone else wants to carry on with the idea, that's fine
> > with me.
>
> Sorry, too late. We're putting serious pressue already on authors who
> posted draft PEPs before the deadline but haven't submitted their text
> to Subversion yet. At this point we have a definite list of PEPs that
> were either checked in or promised on time for the deadline. New
> proposals will have to wait until after 3.0a1 is released (hopefully
> end of June). Also note that the whole stdlib reorg is planned to
> happen after that release.

well, my code is pure python, and can just replace the existing socket.py
module. the _socket module remains in tact. it can surely wait for the
stdlib reorg though, there's no need to rush into it now. i'll submit the
PEP in the near future.

> > non-blocking IO depends greatly on the platform -- and this is
> > exactly why a cross-platform language should standardized that
> > as part of the new IO layer. saying "let's keep it for later" would only
> > require more work at some later stage.
>
> Actually there are only two things platform-specific: how to turn it
> on (or off) and how to tell the difference between "this operation
> would block" and "there was an error".

well, the way i see it, that's exactly why this calls for standardization.

> The struct module has the means to build that out of lower-level reads
> and writes already. If you think a library module to support this is
> needed, write one and make it available as a third party module and
> see how many customers you get. Personally I haven't had the need for
> files containing of fixed-length records of the same type since the
> mid '80s.

not all of us are that lucky :)
there's still lots of protocols ugly protocols and file formats for
us programmers to handle. and TLV structures happen to the be
one of the pretty ones.

> I don't think the new I/O library is the place to put in a bunch of
> new, essentially untried ideas. Instead, we should aim for a flexible
> implementation of APIs that we know work and are needed. I think the
> current stack is pretty flexible in that it supports streams and
> random access, unidirectional and bidirectional, raw and buffered,
> bytes and text. Applications can do a lot with those.

yeah, it was more like a wild idea really. it should be placed in a
different module.


-tomer