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
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
