homepage

The C-API exposed by the `io` module on Python 3.1/3.2 is very limited, and makes interfacing with Python file objects in extension modules difficult.
In more detail:
1) Because the Python layer has buffering etc., the file handle returned by `PyObject_AsFileDescriptor` is not usable as-is. It requires flush and seek before use, every time there is a chance that the file object has been accessed on the Python side. 
2) There are no C-API functions such as the minimal set of `PyFile_Write(buf, length)`, `PyFile_Read(buf, length)`, `PyFile_Seek(pos, whence)`, `PyFile_Tell()`.
Instead, every call must go through PyObject_CallMethod, and the file objects only handle `PyBytes` and `PyByteArray` which are cumbersome and inefficient to use in extension modules.

> Instead, every call must go through PyObject_CallMethod, and the file
> objects only handle `PyBytes` and `PyByteArray` which are cumbersome
> and inefficient to use in extension modules.
Because of the generic nature of the 3.x I/O stack, even shortcuts such as the proposed PyFile_Write will still have to use PyObject_CallMethod(obj, "write", ...) under the hood.
As for the types handled by file objects, you should be able to use a PyMemoryViewObject, which allows you to create a memory buffer without copying it (if that's what you're after).
You can also pass your own objects provided they support the new buffer API: http://docs.python.org/dev/c-api/buffer.html#bufferobjects
(I agree this documentation is not very well written, though)
So, bottom line, we could create a set of PyFile_* wrappers (or, rather, PyStream_*), but they wouldn't be much more efficient that what you can write by hand. Do you still think it's worth it? If so, I think you should float the idea on python-dev (the mailing-list).

I agree with Antoine. If you are still interested to improve the situation then please start a discussion on the python-ideas mailing list.