[Patches] GC patch 3 and 4

Vladimir Marangozov Vladimir.Marangozov@inrialpes.fr
Wed, 28 Jun 2000 18:33:10 +0200 (CEST)


Neil Schemenauer wrote:
>
> On Wed, Jun 28, 2000 at 05:10:22AM +0200, Vladimir Marangozov wrote:
> > For that matter, PyGC_TYPE_HAS_INFO(tp) has to be exported in the public
> > API too, probably under a more friendly name, like PyObject_Check_GC(op)
> > (or better) which would be defined as PyType_HAS_GC(op->ob_type), equivalent
> > to the PyGC_TYPE_HAS_INFO(op->ob_type) ...
>
> I changed them to PyType_IS_GC and PyObject_IS_GC.
>
>   Neil

Good.

BTW, what about the macro/function differenciation regarding the GC API?
For example, the memory API goes as follows:

------
Interface summary
=================

Each memory interface exports both functions and macros. Functions
preserve binary compatibility of the code across different releases
while MACROS trade it for speed.


   Public API       Functions                      MACROS
   --------------   ----------------------------   --------------------

1) Core Memory Allocator (see mymalloc.h)

 - raw mem malloc   PyMem_Malloc/Realloc/Free      PyMem_MALLOC/REALLOC/FREE
 - type-oriented    PyMem_New/Resize/Del           PyMem_NEW/RESIZE/DEL

2) Core Object Memory Allocator & Facilities (see objimpl.h)

 - object malloc    PyObject_Malloc/Realloc/Free   PyObject_MALLOC/REALLOC/FREE
 - initialization   PyObject_Init/InitVar          PyObject_INIT/INIT_VAR
 - constr./destr.   PyObject_New/NewVar/Del        PyObject_NEW/NEW_VAR/DEL

------

In your opinion, what would that be for GC?

Also, I don't think we need all the macros in objimpl.h. For instance,
PyGC_INFO_UNSAFE seems unreasonable. Since it is a capitalized MACRO,
it is supposed to be unsafe. Functions (or lowercased macros) are safe.

Have you considered this issue?

-- 
       Vladimir MARANGOZOV          | Vladimir.Marangozov@inrialpes.fr
http://sirac.inrialpes.fr/~marangoz | tel:(+33-4)76615277 fax:76615252