On 8/20/06, Talin <[EMAIL PROTECTED]> wrote: > Guido van Rossum wrote: > > On 8/20/06, Paul Moore <[EMAIL PROTECTED]> wrote: > > > Without endorsing every detail of his design, tomer filiba has written > > several blog (?) entries about this, the latest being > > http://sebulba.wikispaces.com/project+iostack+v2 . You can also look > > at sandbox/sio/sio.py in svn. > > One comment after reading this: If we're going to re-invent the Java/C# > i/o library, could we at least use the same terminology? In particular, > the term "Layer" has connotations which may be confusing in this context > - I would prefer something like "Adapter" or "Filter".
That's an example of what I meant when I said "without endorsing every detail". I don't know which terminology C++ uses beyond streams. I think Java uses Streams for the lower-level stuff and Reader/Writer for the higher-level stuff -- or is it the other way around? > Also, I notice that this proposal removes what I consider to be a nice > feature of Python, which is that you can take a plain file object and > iterate over the lines of the file -- it would require a separate line > buffering adapter to be created. I think I understand the reasoning > behind this - in a world with multiple text encodings, the definition of > "line" may not be so simple. However, I would assume that the "built-in" > streams would support the most basic, least-common-denominator encodings > for convenience. First time I noticed that. But perhaps it's the concept of "plain file object" that changed? My own hierarchy (which I arrived at without reading tomer's proposal) is something like this: (1) Basic level (implemented in C) -- open, close, read, write, seek, tell. Completely unbuffered, maps directly to system calls. Does binary I/O only. (2) Buffering. Implements the same API as (1) but adds buffering. This is what one normally uses for binary file I/O. It builds on (1), but can also be built on raw sockets instead. It adds an API to inquire about the amount of buffered data, a flush() method, and ways to change the buffer size. (3) Encoding and line endings. Implements a somewhat different API, for reading/writing text files; the API resembles Python 2's I/O library more. This is where readline() and next() giving the next line are implemented. It also does newline translation to/from the platform's native convention (CRLF or LF, or perhaps CR if anyone still cares about Mac OS <= 9) and Python's convention (always \n). I think I want to put these two features (encoding and line endings) in the same layer because they are both text related. Of course you can specify ASCII or Latin-1 to effectively disable the encoding part. Does this make more sense? -- --Guido van Rossum (home page: http://www.python.org/~guido/) _______________________________________________ Python-3000 mailing list [email protected] http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
