> > 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 ;-) </F>
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