fredrik at pythonware.com
Wed Jun 16 21:27:02 CEST 1999
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"...
More information about the Python-Dev