[issue32561] Add API to io objects for non-blocking reads/writes

Nathaniel Smith report at bugs.python.org
Tue Jan 16 03:43:52 EST 2018


Nathaniel Smith <njs at pobox.com> added the comment:

Hmm, why did I use "unbuffered" as my term above? That's a very odd name. It's like, exactly the opposite of what we actually want. Clearly I did not think this through properly. Please pretend I said "buffer-only" instead, thanks.

> So my opinion here is that only raw IO objects (FileIO) should have this functionality.  People can build their own functionality on top of that (such as Tornado or asyncio do with their streams).

I guess I don't object to such functionality, but it would be useless to me personally. FileIO doesn't solve any problems I have with stream processing; the reason I care about this is for providing an async file I/O API. And all the async file IO APIs I know [1][2][3] have the public API of "just like regular files, but the blocking methods are async". 99% of the time, that means TextWrapper and BufferedStream. So I just don't see any way to get the advantages of this feature without either (a) adding buffer-only support to those layers, or (b) forking those layers into a 3rd-party library, and then adding buffer-only support.

OTOH, it would be ok if in an initial implementation some methods like readline() simply always failed when called in buffer-only mode, since this would be a best-effort thing. (This is also a different from the non-blocking semantics discussion in bpo-13322, which is kind of scary. I don't want to deal with partial writes and reads and carrying crucial data in exceptions! I just want to know if the operation can trivially be done without blocking, and if not then I'll retry it in blocking mode.)

[1] https://github.com/Tinche/aiofiles
[2] https://trio.readthedocs.io/en/latest/reference-io.html#asynchronous-filesystem-i-o
[3] https://curio.readthedocs.io/en/latest/reference.html#module-curio.file

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32561>
_______________________________________


More information about the Python-bugs-list mailing list