[Python-Dev] future-proofing vector tables for python APIs: binary-module interoperability (original) (raw)
Roumen Petrov bugtrack at roumenpetrov.info
Sun Jan 25 16:55:47 CET 2009
- Previous message: [Python-Dev] future-proofing vector tables for python APIs: binary-module interoperability
- Next message: [Python-Dev] future-proofing vector tables for python APIs: binary-module interoperability
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Luke Kenneth Casson Leighton wrote:
[SNIP] Yes it is enough to encapsulate memory allocation and file functions into python shared library. The python provide memory allocation functions, but not all modules use them. File functions are hiden by posixmodule and python modules can't use them. except ... posixmodule gets renamed to ntmodule .... oh, i see what you mean: python modules aren't allowed direct access to msvcrtNN's file functions, they have to go via posixmodule-renamed-to-ntmodule. .... thinking about this some more... posixmodule.c is linked (by default) into pythonNN.dll, thus making pythonNN.dll totally dependent on a version of msvcrt.
This is not problem. If python*.dll hide msvcrt and other modules depend directly from python*.dll I expect issue to be resolved. i.e. python*.dll to be "portable runtime interface".
decoupling posixmodule.c from pythonNN.dll leaves the possibility to make python independent of msvcrt versioning.
it would need to be a custom-compiled .pyd module, due to the early dependency. i'll see if this is possible.
Румен
- Previous message: [Python-Dev] future-proofing vector tables for python APIs: binary-module interoperability
- Next message: [Python-Dev] future-proofing vector tables for python APIs: binary-module interoperability
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]