fredrik at pythonware.com
Wed Jun 16 22:04:54 CEST 1999
> > 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"...
> I disagree. Given that a lot of people use Python as a glue language
> for interfacing with legacy codes, it is unacceptable for extensions
> to be forced to use some sort of funky non-standard I/O abstraction.
oh, you're right, of course. should have added that extra smiley
to that last line. cut and paste from this mail if necessary: ;-)
> Unless you are volunteering to rewrite all of these codes to use the
> new I/O model, you are always going to need access (in one way or
> another) to plain old 'FILE *' and integer file descriptors. Of
> course, one can always just provide a function like
> FILE *PyFile_AsFile(PyObject *o)
> That takes an I/O object and returns a 'FILE *' where supported.
exactly my idea. when scanning the code, PyFile_AsFile immediately
popped up as a potential pothole (if you need the fileno, there's
already a method for that in the "standard file object interface").
btw, an "abstract file object" could actually make it much easier
to support arbitrary file objects from C/C++ extensions. just map
the calls back to Python. or add a tp_file slot, and things get
> (Of course, if it's not supported, then it doesn't matter if this
> function is missing since any extension that needs a 'FILE *' wouldn't
> work anyways).
yup. I suspect some legacy code may have a hard time running
under CE et al. but of course, with a little macro trickery, no-
thing stops you from recompiling such code so it uses Python's
new "abstract file... okay, okay, I'll stop now ;-)
More information about the Python-Dev