Fredrik Lundh writes:
>
> 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.
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. (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).
Cheers,
Dave
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4