RetroSearch Browse

Sun Jan 25 16:55:47 CET 2009 · http://mail.python.org/pipermail/python-dev/2009-January/085441.html

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.

Румен

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Showing content from http://mail.python.org/pipermail/python-dev/2009-January/085441.html below:

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