[Python-Dev] mmap

Fredrik Lundh 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
really interesting...

> (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 mailing list