Skip to content Skip to sidebar Skip to footer

Backward Compatibility Of Python 3.5 For External Modules

I have built a Python C++ module based on Python 3.4.3. Later I have installed Python 3.5, and tried to load my Python module. When I tried to do so, I got the following error: Imp

Solution 1:

By default, Python only tries to provide source compatibility across releases, not binary compatibility; recompilation is usually required (and always required on Windows due to explicitly linking a minor release specific version of the Python core DLL).

Starting in 3.2 though, extensions can opt in to a limited version of the API that is guaranteed to remain ABI compatible across Python releases, so recompilation isn't necessary, by defining Py_LIMITED_API. You can read more details about using the stable ABI on the Python docs or on PEP 384 which defined the concept of the stable ABI in the first place.

Solution 2:

C (or C++) extension modules are linked against the Python DLL of the interpreter they are compiled for, so it's not just the version number that has to match but also the architecture it was compiled for (operating system and 32 vs. 64 bits). Trying to import such an extension module with another intepreter with a different runtime DLL leads to the exception you got.

Depending on the extension you might try to compile it into a DLL with a C API and use the ctypes module to interface the DLL. As long as the Python module to interface the DLL is portable across the targeted Python versions, the shared library is portable, only limited by the 32 vs. 64 bit choice.

Post a Comment for "Backward Compatibility Of Python 3.5 For External Modules"