On 31/08/2010 7:54 AM, Nick Coghlan wrote:
On Tue, Aug 31, 2010 at 12:47 AM, Michael Foord
<fuzzy...@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
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
