Charles-François Natali <neolo...@free.fr> added the comment:
> But then what's the point of using buffered I/O at all? If it can't
> offer anything more than raw I/O, I'd rather do something like raise
> a RuntimeError("buffered I/O doesn't work with non-blocking streams")
> when the raw stream returns None.
Well, ideally it should be an UnsupportedOperation, but that's an option. The
only think I didn't like about this is that we should ideally raise this error
upon the first method call, not when - and if - we receive EAGAIN.
Another possibility would be that, since lines are usually reasonably sized,
they should fit in the buffer (which is 8KB by default). So we could do the
extra effort of buffering the data and return it once the line is complete: if
the buffer fills up before we got the whole line, then we could raise a
RuntimeError("Partial line read"). Note that I didn't check if it's easily
feasible (i.e. we should avoid introducing kludges in the I/O layer just to
handle thi corner case).
> Returning partial results on a buffered's readline() is not something
> we should ever do.
Yeah, I know.
Java made the choice of making readline() block, which is IMHO even worse (I
mean, it defeats the whole point of non-blocking I/O...).
----------
_______________________________________
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue13322>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
