<<<Much good stuff deleted...>>>
> int PyObject_Print(PyObject *o, FILE *fp, int flags)
>
> Print an object, o, on file, fp. Returns -1 on
> error. The flags argument is used to enable certain printing
> options. The only option currently supported is Py_Print_RAW.
>
> (What should be said about Py_Print_RAW?)
It seems to me that 'fp' should be a PyObject* instead of a FILE*, pointing
to an object that acted like a file. This has several advantages:
1) "Printing" can be to non-file objects, as long as the correct interface
is supported. This would be useful, for instance, if the output needed
to be encrypted or stored in a packet and sent over a socket or written
to some sort of window object or ... . I very often wish that stdio
allowed me to build FILE objects that could do more than work on file
streams!
The ability to actually print to a FILE* object is not lost, since a
Python object can be built to support this.
2) If in the future it were decided that Python should not use stdio for
its files, using a Python object here will lead to one less compatability
problem. [One reason to avoid stdio might be to support buffered socket
objects that need to interact with select() in a portable manner. Another
reason might be to improve I/O efficiency, or to provide a more Posix-like
interface to all 'file' objects...]
PyFile_FromFile would probably need to be reexamined if anyone seriously
thought about replacing stdio with some other I/O mechanism.
Other than this point, I think the proposal looks pretty good.
-- R. Lindsay Todd, Systems Programmer, Rensselaer Polytechnic Institute, Troy NY toddr@rpi.edu / 518-276-2605 / http://www.rpi.edu/~toddr/Home.html