[Pythonmac-SIG] Re: INCREMENTING & DECREMENTING PyObjects

[Jack Jansen]

Recently, Etienne Antoniutti Di Muro <etienne@alias.it> said:
>  result = PyObject_GetAttrString(aPythonClass, aMethodName); // ie a aPythonC
> lass
> method
>  // Py_INCREFS aPythonClass, thus Py_DECREF(aPythonClass) is needed  to
> mantain ref
> count correct within the C code.


No, please don't do that! The reference count to aPythonClass indeed
increments, but that has a completely different reason. The method
object carries a reference to the class.
> 
> // anyway this makes a lot of sense.
> 
> """
> 
> I'm wondering if I'll find similar behaviours with different embedding
> funcitons......i.e. PyObject_CallMethod(PyObject *o, char *name, char
> *format, ...)
> 
> This is a pretty interesting and handy function, and I intensively use
> it , but it
> is scarcely referenced in Python manuals & companions, while
> PyEval_CallObject is
> exaustively described.

Probably because it wasn't written by Guido:-). It is a convenience
function in Object/abstract.c. You can always download the source (or
browse it on python.sourceforge.org), but in this case I'l tell you
that it does it's refcounting correctly. You are of course responsible 
for decreffing the return value.

> 2-
> The INCREMENTING & DECREMENTING PyObjects question in this Thread title
> was because
> i'm running into problems with
> Python memory management.The set of python functions I run, is embedded
> into a C
> GUI on the Macintosh. Since the interpreter does *NOT DEALLOCATES*
> memory when I
> release PyObjects used either by the gui and the interpreter, I was
> supposing that
> it was my fault in increffing and decreffing objects.

This is a question that has many answers. A general answer is that it
could be caused by circular references. Python has no "real" garbage
collection, so if a number of objects have circular references to each 
other they will never be released.

Another answer is that under MacPython 1.5.2 (not under 2.0 anymore)
it used its own malloc(). This used to be quite a bit faster (about a
20% increase in Python's speed), but memory that was once allocated to 
Python's malloc would never be returned to the system pool. (It would
be re-used for other Python objects, but usually only for objects of a 
similar size). Recently the CodeWarrior malloc() has gotten a lot
better, so as of 2.0 MacPython uses the standard malloc().

If you use MacPython 1.5.2 then MetroWerks ZoneRanger can provide
quite a bit of insight. You can also recompile MacPython with
MALLOC_DEBUG, which not only makes malloc/free do consistency checks
but also gives you a dump routine you can call through a method in the 
MacOS module (sorry, forgot the name). Under 2.0 all this doesn't work 
anymore, but you could probably re-enable the private malloc (the
sources are still there).

What may be even better (and also works under 2.0) is recompiling
Python with Py_REF_DEBUG or Py_TRACE_REFS.
--
Jack Jansen             | ++++ stop the execution of Mumia Abu-Jamal ++++
Jack.Jansen@oratrix.com | ++++ if you agree copy these lines to your sig ++++
www.oratrix.nl/~jack    | see http://www.xs4all.nl/~tank/spg-l/sigaction.htm