Le mercredi 20 octobre 2010 à 00:48 +0200, "Martin v. Löwis" a écrit :
Also, the canonical way to do file I/O in Python 3 is the `io` lib, therefore it would be a bit of a shame to have separate, non-integrated `aio_*` functions.
I disagree. We also have posix.open, posix.dup, etc. We always expose POSIX functions in the posix module (except for the socket functions, unfortunately, and a few other exceptions), and I see no reason to break with this tradition. The io module should be thought of as sitting on top of the posix module (and it initially was).
I'm not suggesting to break with any "tradition", but that building duplicate APIs to do file I/O has little value and only makes things more cumbersome.
Also, since the `io` lib is already supposed to support non-blocking IO, perhaps it would be valuable to stress this support and propose any interesting patches for fixing and/or improving it.
I think that's entirely independent.
I don't think it is. If the goal is to give ways to improve file I/O performance for specialized use cases, then it certainly deserves integration with the current I/O stack. If the goal is not that, then I don't really know what it is.
It would be nice to know about the use case Jesus has in mind.