[Python-Dev] PEP 384 status
Mark Hammond
skippy.hammond at gmail.com
Tue Aug 31 06:15:42 CEST 2010
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
More information about the Python-Dev
mailing list