I've been thinking more about the iostack proposal. Right now, a typical file handle consists of 3 "layers" - one representing the backing store (file, memory, network, etc.), one for adding buffering, and one representing the program-level API for reading strings, bytes, decoded text, etc.
I wonder if it wouldn't be better to cut that down to two. Specifically, I would like to suggest eliminating the buffering layer. My reasoning is fairly straightforward: Most file system handles, network handles and other operating system handles already support buffering, and they do a far better job of it than we can. The handles that don't support buffering are memory streams - which don't need buffering anyway. Of course, it would make sense for Python to provide its own buffering implementation if we were going to always use the lowest-level i/o API provided by the operating system, but I can't see why we would want to do that. The OS knows how to allocate an optimal buffer, using information such as the block size of the filesystem, whereas trying to achieve this same level of functionality in the Python standard library would be needlessly complex IMHO. -- Talin _______________________________________________ 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
