Antoine Pitrou <pit...@free.fr> added the comment: > 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. ---------- _______________________________________ 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
