David Beazley wrote:
I am not in favor of obscuring Python's I/O model too much. When working with C extensions, it is critical to have access to normal I/O mechanisms such as 'FILE *' or integer file descriptors. If you hide all of this behind some sort of abstract I/O layer, it's going to make life hell for extension writers unless you also provide a way to get access to the raw underlying data structures. This is a major gripe I have with the Tcl channel model--namely, there seems to be no easy way to unravel a Tcl channel into a raw file-descriptor for use in C (unless I'm being dense and have missed some simple way to do it).
Also, what platforms are we talking about here? I've never come across any normal machine that had a C compiler, but did not have stdio. Is this really a serious problem?
in a way, it is a problem today under Windows (in other words, on most of the machines where Python is used today). it's very easy to end up with different DLL's using different stdio implementations, resulting in all kinds of strange errors. a rewrite could use OS-level handles instead, and get rid of that problem. not to mention Windows CE (iirc, Mark had to write his own stdio-ish package for the CE port), maybe PalmOS, BeOS's BFile's, and all the other upcoming platforms which will make Windows look like a fairly decent Unix clone ;-) ... and in Python, any decent extension writer should write code that works with arbitrary file objects, right? "if it cannot deal with StringIO objects, it's broken"... </F>