This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author pitrou
Recipients benjamin.peterson, martin.panter, njs, pitrou, stutzbach, xgdomingo
Date 2018-01-16.08:51:32
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1516092693.0.0.467229070634.issue32561@psf.upfronthosting.co.za>
In-reply-to
Content
> 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.

Yeah... The concrete problem is that there's already a poorly thought-out "non-blocking mode" that only partly works, and suddenly the code (which includes a lot of delicate, performance-critical C code... to give you an idea, even recently a consistency bug in truncate() was discovered) will have to be massaged to support another non-blocking mode of operation.

So that's why I'm very cautious about integrating this into BufferedReader and friends.
History
Date User Action Args
2018-01-16 08:51:33pitrousetrecipients: + pitrou, benjamin.peterson, stutzbach, njs, martin.panter, xgdomingo
2018-01-16 08:51:33pitrousetmessageid: <1516092693.0.0.467229070634.issue32561@psf.upfronthosting.co.za>
2018-01-16 08:51:32pitroulinkissue32561 messages
2018-01-16 08:51:32pitroucreate