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

[Roumen Petrov]

Luke Kenneth Casson Leighton wrote:
> On Fri, Jan 23, 2009 at 10:48 PM, Roumen Petrov
[SNIP]
> but it would certainly mean that there would be both a future-proof
> path for binary modules from either msvc-compiled _or_ mingw-compiled
> 2.5, 2.6, 2.7 etc. to work with 2.5, 2.6, 2.7, 2.8 etc. _without_ a
> recompile.  [forwards-future-proof-compatibility _is_ possible, but...
> it's a bit more... complicated.  backwards-compatibility is easy].
> 
> what you do is you make sure that the vector-table is always and only
> "extended" - added to - never "removed from" or altered.  if one
> function turns out to be a screw-up (inadequate, not enough
> parameters), you do NOT change its function parameters, you add an
> "Ex" version - or an "Ex1" version.
[SNIP]
> 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
> it's actually _already_ in use in one form in the way that python
> objects are typecast from PyObject to other types of structs!  the
> difference is that a bit-field would make detection of revisions a bit
> easier but to be honest you could just as easily make it an int and
> increase the revision number.

This look like simple RCP implemantation.
If I remember well SUN-RPC assign number to program, function, version.

[SNIP]
> 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.


Roumen