On 31/08/2010 7:54 AM, Nick Coghlan wrote:
On Tue, Aug 31, 2010 at 12:47 AM, Michael Foord <fuzzyman@voidspace.org.uk> wrote:
An extension compiled for one version of Python will be linked against the version of the C runtime used by that version of Python (if it is compiled with the same version of Visual Studio of course).
If the extension binary is to remain compatible with a later version of Python, compiled against a different version of the C runtime, then it *must* be possible for multiple C runtimes to be loaded. If the stable ABI doesn't allow this then binaries will *still* have to be recompiled when we update the version of Visual Studio used to compile Python - defeating the purpose of the PEP. Right?
If this is the case then I agree that it should be explicit in the PEP.
Ah, I knew it was explicit in the PEP somewhere. The following is currently mentioned in the "Excluded Functions" section:
"In addition, functions expecting FILE* are not part of the ABI, to avoid depending on a specific version of the Microsoft C runtime DLL on Windows."
It would be interesting to know how, in practice, these FILE pointers come to life. In my experience they are generally obtained via fopen. If that is broadly true, then a middle-ground may be for Python to expose something like Py_fopen, Py_fclose and a PyFILE opaque "handle". API elements which currently take a FILE * could be exposed using a PyFILE * in the ABI. People who didn't care about this level of portability could continue to use the non-ABI FILE * functions, but people who do could use Py_fopen/Py_fclose in place of fopen/fclose but otherwise work as now. A downside is that as mentioned, in practice these FILE pointers may come from more than simply fopen, so few people would be able to leverage this. It also assumes that people open files before handing them to Python, but otherwise don't use that file - it would be a slippery-slope to wind up with Py_fread etc. Mark