version independant object usage counting

[Rolf Kalbermatter]

> -----Original Message-----
> From: python-list-admin at python.org
> [mailto:python-list-admin at python.org]On Behalf Of Martin v. Lowis
> Sent: Monday, September 02, 2002 3:38 PM
> To: python-list at python.org
> Subject: Re: version independant object usage counting
>
>
> "Rolf Kalbermatter" <rolf.kalbermatter at citeng.com> writes:
>
> > 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.
>
> Yes, this is the case - mainly because the API changes in slight ways,
> and because therefore, extension modules explicitly link to
> pythonxy.dll.

I realize that extension modules might get other problems with API changes
and that this is more likely to be a problem than the layout of the object
interface.

> > 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.
>
> That is only a minor problem: those macros are correct across all
> released Python versions, back to 1.4 or earlier.

But there is a serious difference between the DEBUG and NON-DEBUG
PyObject_HEAD structure layout which I would like to not have to worry
about if possible. As I'm really embedding Python (in this case into
LabVIEW), by trying to access the whole Python core as version independant
as possible I want to make it unimportant if the Python DLL is compiled
as DEBUG or non DEBUG or actually what version it really is.

> > 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?
>
> Nobody has proposed to introduce them, because there is no need to do
> so, and because other ABI changes break the ABI more often - INCREF
> and DECREF have never done so, and it is unlikely that they ever will.
>
> > Any thought about this?
>
> Feel free to submit a patch to SourceForge. However, you might want to
> consider the following issues:

Does anyone see any problems with this code?

RCS file: /cvsroot/python/python/dist/src/Include/object.h,v
retrieving revision 2.111
diff -c -2 -r2.111 object.h
*** object.h	8 Aug 2002 20:55:20 -0000	2.111
--- object.h	2 Sep 2002 13:44:46 -0000
***************
*** 347,350 ****
--- 347,352 ----

  /* Generic operations on objects */
+ PyAPI_FUNC(int) PyObject_IncRef(PyObject *);
+ PyAPI_FUNC(int) PyObject_DecRef(PyObject *);
  PyAPI_FUNC(int) PyObject_Print(PyObject *, FILE *, int);
  PyAPI_FUNC(void) _PyObject_Dump(PyObject *);


diff -c -2 -r2.192 object.c
*** objects/object.c	24 Aug 2002 06:31:34 -0000	2.192
--- objects/object.c	2 Sep 2002 13:51:37 -0000
***************
*** 166,169 ****
--- 166,191 ----

  int
+ PyObject_IncRef(PyObject *op)
+ {
+ 	if (op) {
+ 		Py_INCREF(op);
+ 		return op->ob_refcnt;
+ 	}
+ 	return 0;
+ }
+
+ int
+ PyObject_DecRef(PyObject *op)
+ {
+ 	if (op) {
+ 		int refcnt = op->ob_refcnt;
+ 		Py_DECREF(op);
+ 		if (refcnt > 1)
+ 			return op->ob_refcnt;
+ 	}
+ 	return 0;
+ }
+
+ int
  PyObject_Print(PyObject *op, FILE *fp, int flags)
  {

This interface explicitedly would not require anymore to import _Py_Dealloc
and _Py_RefTotal which are only implemented and therefore exported from
DEBUG
core DLLs. It would still be anybodies own decision if to use the existing
macros or the according accessor functions instead.

> - various places assume presence of the ob_type field:
>   * the Py*_Check functions (e.g. PyList_Check) directly access the
>     ob_type field.

Hmm. I see your point in this. However I check this by having a private
PyObject_MyCheckType defined which accesses the ob_type field over the
PyObject_Type function and then checking for specific type through
PyObject_MyCheckType(op, &Py_<Type>).

>   * PyObject_INIT relies on initializing the object members.
> - PyType_HasFeature relies on the position of the tp_flags field

I'm not using these function at all until now. May have to do so when
I start to add an extension module however?

> - various accessor macros rely on the internal structure, e.g.
>   * PyTuple_GET_ITEM
>   * PyString_AS_STRING
>   * ...

I try to avoid them and use the according function interface instead such as
PyString_AsString() which was successful until now.

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