version independant object usage counting

Rolf Kalbermatter rolf.kalbermatter at citeng.com
Mon Sep 2 04:51:18 EDT 2002


Hello there,

I'm fairly new in Python and have attempted to do embedding of the Python
core in
another application on Windows NT and succeeded so far. In doing this work I
found
out that Python clients (applications, modules and such) are always linked
with a
version specific import library which even makes a difference for debug and
non-debug.

In using and programming DLLs until now I was always used to attempt to
remove
version dependances as much as possible and so thought about implementing my
own
Python DLL loader to achive full weak linking to Python and possibly allow a
configuration setting to specify where and which Python core DLL to use.
However
although this loader works quite fine now, I found out that I gained little
with
it because the current Python architecture is not really designed to link
dynamically
to it.

Of course more complicated tools may be very difficult or impossible to keep
version
independant but in my case I just call some standard functions from the
Python core
DLL. The problem arises in fact with the refcounting of Python objects. The
macros
Py_INCREF and Py_DECREF access directly structure members in the object
layout and
this layout is different for debugging and non debugging versions and
potentially
different between Python versions as well. By adding two new API functions
PyObject_AddRef() and PyObject_Release() or whatever name seems appropriate
and
exporting them, it would be possible to write clients which import the
necessary
Python API functions dynamically on there own and link to a specific Python
DLL/shared
library much more independant from the used Python core DLL than it is the
case now.

Is there a specific reason that these two API functions are not available
and one
is forced to use the according macros to do proper refcounting, or did I
miss those
functions completely? I do understand that inline code is a little faster
than calling
a function and I do not propose to remove the current macros at all, but
rather would
like to see two additional functions added which allow to do proper refcount
manipulation
over a functional interface instead of direct object structure layout
access.

Any thought about this?

Rolf Kalbermatter
CIT Engineering Nederland BV    tel: +31 (070) 415 9190
Treubstraat 7H                           fax: +31 (070) 415 9191
2288 EG Rijswijk	http://www.citengineering.com
Netherlands		mailto:rolf.kalbermatter at citeng.com






More information about the Python-list mailing list