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." To make that explicit in the Rationale section, I would append a second sentence to the final paragraph of that section (the first sentence is already there): "With this PEP, it will be possible to reduce the dependency of binary extension modules on a specific Python feature release, and applications embedding Python can be made work with different releases. To ensure this is also achieved on Windows, the ABI will be designed to allow the Python binary and extension modules or an embedding application to depend on different versions of the C runtime DLL." I would also make the following modification to the above quoted paragraph from the Excluded Functions section of the PEP: "To avoid depending on a specific version of the Microsoft C runtime DLL on Windows while still providing a consistent, cross-platform API when PY_LIMITED_API is defined, the following functions are also excluded: - Any functions accepting or returning FILE* (as this is defined in the C standard as an implementation dependent opaque reference. On Windows, it is known to contain reference to runtime-specific global data) - Any functions reliant on global or thread local state expected to be modified by C standard library calls rather than other Python API calls (e.g. PyErr_FromErrno will be unavailable. Comparable functionality will be provided by a new function PyErr_FromErrnoEx, with the latter accepting an explicit errno parameter) Where practical, equivalent functionality for the excluded functions will instead be provided using preprocessor macros. This ensures that the use of the C runtime dependent types and data remains separate without significantly complicating extension module development and the API remains compatible with any C89 compiler. Note that locale dependent operations will still be available, they just may not see locale changes made via the C standard library calls. Locale changes will need to be made via Python API calls to the locale module to ensure they are seen correctly by the interpreter." Hmm... that last point is a bit of any issue actually, since it also flows the other way (changes made via the locale module won't be visible to any extension modules using a different C runtime). So I suspect mixing C runtimes is still going to come with the caveat of potential locale related glitches. Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia