[Python-Dev] future-proofing vector tables for python APIs: binary-module interoperability

Roumen Petrov bugtrack at roumenpetrov.info
Sun Jan 25 16:55:47 CET 2009


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.

Румен


More information about the Python-Dev mailing list