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

[Luke Kenneth Casson Leighton]

>> but basically, not only is this technique nothing new - it's in use in
>> Apache RunTime, FreeDCE, the NT Kernel, the Linux Kernel - but also

> This look like simple RPC implemantation.

 yep.

> If I remember well SUN-RPC assign number to program, function, version.

 yep - i forgot about that one: yes, that's another example.  this is
pretty basic well-understood, well-documented techniques that
virtually every large project that requires isolation between
components (and an upgrade path) ends up using in one form or another.

the only fly in the ointment will be that putting pointers to
PyType_String etc. etc. into a vector table (struct), you end up with
an extra de-ref overhead, which is often an argument utilised to do
away with vector tables.  but - tough: the decision involves getting
away from "Hell" to something that makes everyone's lives that much
easier, it's an easy decision to make.


>> surely, that should be the _only_ dll which gets _specifically_ linked
>> against msvcr71.dll (or 90, or... whatever) and it would be even
>> _better_ if that then got _named_ msvcr71.pyd, msvcr90.pyd etc.
>
> [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.

 so it's still ok.

 l.