[Python-3000] Comment on iostack library
Talin
talin at acm.org
Wed Aug 30 06:00:49 CEST 2006
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
More information about the Python-3000
mailing list