Author njs
Recipients benjamin.peterson, martin.panter, njs, pitrou, stutzbach, xgdomingo
Date 2018-01-16.08:43:51
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <>
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.)

Date User Action Args
2018-01-16 08:43:52njssetrecipients: + njs, pitrou, benjamin.peterson, stutzbach, martin.panter, xgdomingo
2018-01-16 08:43:52njssetmessageid: <>
2018-01-16 08:43:52njslinkissue32561 messages
2018-01-16 08:43:51njscreate