Nathaniel Smith <n...@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 <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

Reply via email to