Nathaniel Smith <n...@pobox.com> added the comment:
> BufferedIOBase is an abstract class and, despite the name, doesn’t
> necessitate a buffer or cache
Right, sorry, skimmed too fast.
> In Issue 32475 there is a proposal to add a “getbuffn” method returning the
> amount of unread pending data in a reader object. Perhaps that would be
> enough for reading.
Ideally we would be able to do buffer-only reads through all the of the
different read methods (read, readline, readinto, ...), and ideally we would be
able to do it given objects at different points in the IO stack – so a
buffer-only read on TextWrapper wrapped around a BufferedRandom wrapped around
a FileIO, should propagate the buffer-only-ness all the way down the stack. I
don't think getbuffn is enough to solve that? Or at least I don't see how in
any simple way.
Also, the immediate thing that spurred me to file this issue was learning that
Linux has just added a non-blocking file read syscall. It would be pretty neat
if we could expose that. If we had a way to propagate this down, then it could
just be FileIO's implementation of the buffer-only flag.
But yeah, actually doing that is complicated given the need to continue
supporting existing implementations of these interfaces.
Here's a straw man proposal: add a unbuffered_supported flag to the abstract IO
interfaces. If missing or false, you can't do unbuffered reads/writes. If
present and True, then you can pass a new unbuffered=True kw-only argument to
their read/write calls.
When (for example) TextWrapper.read needs to call its wrapped object's .read,
it does a check like:
if unbuffered:
# This call is unbuffered, so we're only allowed to call
# unbuffered methods.
if not getattr(self.wrapped, "unbuffered_supported", False):
# lower level doesn't support this, can't be done
raise ...
else:
self.wrapped.read(..., unbuffered=True)
else:
# We're a regular call, so we can make a regular call
self.wrapped.read(...)
(I'm intentionally using "unbuffered" here to distinguish from regular POSIX
"non-blocking", which is an API that's conceptually very similar but totally
distinct in implementation. Especially since it's also possible to use the io
stack with sockets/pipes in non-blocking mode.)
----------
_______________________________________
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue32561>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
