[Python-Dev] PEP 384 status

[Nick Coghlan]

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."

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 at gmail.com   |   Brisbane, Australia