[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