[Python-Dev] Buffered streams design + raw io gotchas

Sat Feb 20 12:20:39 CET 2010

Allright, so in the case of regular files I may content myself of 
BufferedRandom.
And maybe I'll put some warnings concerning the returning of raw streams 
by factory functions.
Thanks,
Regards,
Pascal
Guido van Rossum a écrit :
> IIRC here is the use case for buffered reader/writer vs. random: a
> disk file opened for reading and writing uses a random access buffer;
> but a TCP stream stream, while both writable and readable, should use
> separate read and write buffers. The reader and writer don't have to
> worry about reversing the I/O direction.
>> But maybe I'm missing something about your question?
>> --Guido
>> On Thu, Feb 18, 2010 at 1:59 PM, Pascal Chambon
> <chambon.pascal at gmail.com> wrote:
>>> Hello,
>>>> As I continue experimenting with advanced streams, I'm currently beginning
>> an important modification of io's Buffered and Text streams (removal of
>> locks, adding of methods...), to fit the optimization process of the whole
>> library.
>> However, I'm now wondering what the idea is behind the 3 main buffer classes
>> : Bufferedwriter, Bufferedreader and Bufferedrandom.
>>>> The i/o PEP claimed that the two first ones were for sequential streams
>> only, and the latter for all kinds of seekable streams; but as it is
>> implemented, actually the 3 classes can be returned by open() for seekable
>> files.
>>>> Am I missing some use case in which this distinction would be useful (for
>> optimizations ?) ? Else, I guess I should just create a RSBufferedStream
>> class which handles all kinds of situations, raising InsupportedOperation
>> exceptions whenever needed.... after all, text streams act that way (there
>> is no TextWriter or TextReader stream), and they seem fine.
>>>> Also, io.open() might return a raw file stream when we set buffering=0. The
>> problem is that raw file streams are NOT like buffered streams with a buffer
>> limit of zero : raw streams might fail writing/reading all the data asked,
>> without raising errors. I agree this case should be rare, but it might be a
>> gotcha for people wanting direct control of the stream (eg. for locking
>> purpose), but no silently incomplete read/write operation.
>> Shouldn't we rather return a "write through" buffered stream in this case
>> "buffering=0", to cleanly handle partial read/write ops ?
>>>> regards,
>> Pascal
>>>> PS : if you have 3 minutes, I'd be very interested by your opinion on the
>> "advanced modes" draft below.
>> Does it seem intuitive to you ? In particular, shouldn't the "+" and "-"
>> flags have the opposite meaning ?
>> http://bytebucket.org/pchambon/python-rock-solid-tools/wiki/rsopen.html
>>>>>>>> _______________________________________________
>> Python-Dev mailing list
>> Python-Dev at python.org
>> http://mail.python.org/mailman/listinfo/python-dev
>> Unsubscribe:
>> http://mail.python.org/mailman/options/python-dev/guido%40python.org
>>>>>>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20100220/2bc90858/attachment.htm>