[Python-Dev] PEP 384 status

[Mark Hammond]

On 31/08/2010 7:54 AM, Nick Coghlan wrote:
> On Tue, Aug 31, 2010 at 12:47 AM, Michael Foord
> <fuzzyman at 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