cpython/Objects/tupleobject.c

576 lines
13 KiB
C
Raw Normal View History

1991-02-19 08:39:46 -04:00
/***********************************************************
2000-06-30 20:50:40 -03:00
Copyright (c) 2000, BeOpen.com.
Copyright (c) 1995-2000, Corporation for National Research Initiatives.
Copyright (c) 1990-1995, Stichting Mathematisch Centrum.
All rights reserved.
See the file "Misc/COPYRIGHT" for information on usage and
redistribution of this file, and for a DISCLAIMER OF ALL WARRANTIES.
1991-02-19 08:39:46 -04:00
******************************************************************/
1990-10-14 09:07:46 -03:00
/* Tuple object implementation */
1997-05-02 00:12:38 -03:00
#include "Python.h"
1990-10-14 09:07:46 -03:00
Patch by Charles G Waldman to avoid a sneaky memory leak in _PyTuple_Resize(). In addition, a change suggested by Jeremy Hylton to limit the size of the free lists is also merged into this patch. Charles wrote initially: """ Test Case: run the following code: class Nothing: def __len__(self): return 5 def __getitem__(self, i): if i < 3: return i else: raise IndexError, i def g(a,*b,**c): return for x in xrange(1000000): g(*Nothing()) and watch Python's memory use go up and up. Diagnosis: The analysis begins with the call to PySequence_Tuple at line 1641 in ceval.c - the argument to g is seen to be a sequence but not a tuple, so it needs to be converted from an abstract sequence to a concrete tuple. PySequence_Tuple starts off by creating a new tuple of length 5 (line 1122 in abstract.c). Then at line 1149, since only 3 elements were assigned, _PyTuple_Resize is called to make the 5-tuple into a 3-tuple. When we're all done the 3-tuple is decrefed, but rather than being freed it is placed on the free_tuples cache. The basic problem is that the 3-tuples are being added to the cache but never picked up again, since _PyTuple_Resize doesn't make use of the free_tuples cache. If you are resizing a 5-tuple to a 3-tuple and there is already a 3-tuple in free_tuples[3], instead of using this tuple, _PyTuple_Resize will realloc the 5-tuple to a 3-tuple. It would more efficient to use the existing 3-tuple and cache the 5-tuple. By making _PyTuple_Resize aware of the free_tuples (just as PyTuple_New), we not only save a few calls to realloc, but also prevent this misbehavior whereby tuples are being added to the free_tuples list but never properly "recycled". """ And later: """ This patch replaces my submission of Sun, 16 Apr and addresses Jeremy Hylton's suggestions that we also limit the size of the free tuple list. I chose 2000 as the maximum number of tuples of any particular size to save. There was also a problem with the previous version of this patch causing a core dump if Python was built with Py_TRACE_REFS. This is fixed in the below version of the patch, which uses tupledealloc instead of _Py_Dealloc. """
2000-04-21 18:15:05 -03:00
/* Speed optimization to avoid frequent malloc/free of small tuples */
#ifndef MAXSAVESIZE
Patch by Charles G Waldman to avoid a sneaky memory leak in _PyTuple_Resize(). In addition, a change suggested by Jeremy Hylton to limit the size of the free lists is also merged into this patch. Charles wrote initially: """ Test Case: run the following code: class Nothing: def __len__(self): return 5 def __getitem__(self, i): if i < 3: return i else: raise IndexError, i def g(a,*b,**c): return for x in xrange(1000000): g(*Nothing()) and watch Python's memory use go up and up. Diagnosis: The analysis begins with the call to PySequence_Tuple at line 1641 in ceval.c - the argument to g is seen to be a sequence but not a tuple, so it needs to be converted from an abstract sequence to a concrete tuple. PySequence_Tuple starts off by creating a new tuple of length 5 (line 1122 in abstract.c). Then at line 1149, since only 3 elements were assigned, _PyTuple_Resize is called to make the 5-tuple into a 3-tuple. When we're all done the 3-tuple is decrefed, but rather than being freed it is placed on the free_tuples cache. The basic problem is that the 3-tuples are being added to the cache but never picked up again, since _PyTuple_Resize doesn't make use of the free_tuples cache. If you are resizing a 5-tuple to a 3-tuple and there is already a 3-tuple in free_tuples[3], instead of using this tuple, _PyTuple_Resize will realloc the 5-tuple to a 3-tuple. It would more efficient to use the existing 3-tuple and cache the 5-tuple. By making _PyTuple_Resize aware of the free_tuples (just as PyTuple_New), we not only save a few calls to realloc, but also prevent this misbehavior whereby tuples are being added to the free_tuples list but never properly "recycled". """ And later: """ This patch replaces my submission of Sun, 16 Apr and addresses Jeremy Hylton's suggestions that we also limit the size of the free tuple list. I chose 2000 as the maximum number of tuples of any particular size to save. There was also a problem with the previous version of this patch causing a core dump if Python was built with Py_TRACE_REFS. This is fixed in the below version of the patch, which uses tupledealloc instead of _Py_Dealloc. """
2000-04-21 18:15:05 -03:00
#define MAXSAVESIZE 20 /* Largest tuple to save on free list */
#endif
#ifndef MAXSAVEDTUPLES
#define MAXSAVEDTUPLES 2000 /* Maximum number of tuples of each size to save */
#endif
#if MAXSAVESIZE > 0
Patch by Charles G Waldman to avoid a sneaky memory leak in _PyTuple_Resize(). In addition, a change suggested by Jeremy Hylton to limit the size of the free lists is also merged into this patch. Charles wrote initially: """ Test Case: run the following code: class Nothing: def __len__(self): return 5 def __getitem__(self, i): if i < 3: return i else: raise IndexError, i def g(a,*b,**c): return for x in xrange(1000000): g(*Nothing()) and watch Python's memory use go up and up. Diagnosis: The analysis begins with the call to PySequence_Tuple at line 1641 in ceval.c - the argument to g is seen to be a sequence but not a tuple, so it needs to be converted from an abstract sequence to a concrete tuple. PySequence_Tuple starts off by creating a new tuple of length 5 (line 1122 in abstract.c). Then at line 1149, since only 3 elements were assigned, _PyTuple_Resize is called to make the 5-tuple into a 3-tuple. When we're all done the 3-tuple is decrefed, but rather than being freed it is placed on the free_tuples cache. The basic problem is that the 3-tuples are being added to the cache but never picked up again, since _PyTuple_Resize doesn't make use of the free_tuples cache. If you are resizing a 5-tuple to a 3-tuple and there is already a 3-tuple in free_tuples[3], instead of using this tuple, _PyTuple_Resize will realloc the 5-tuple to a 3-tuple. It would more efficient to use the existing 3-tuple and cache the 5-tuple. By making _PyTuple_Resize aware of the free_tuples (just as PyTuple_New), we not only save a few calls to realloc, but also prevent this misbehavior whereby tuples are being added to the free_tuples list but never properly "recycled". """ And later: """ This patch replaces my submission of Sun, 16 Apr and addresses Jeremy Hylton's suggestions that we also limit the size of the free tuple list. I chose 2000 as the maximum number of tuples of any particular size to save. There was also a problem with the previous version of this patch causing a core dump if Python was built with Py_TRACE_REFS. This is fixed in the below version of the patch, which uses tupledealloc instead of _Py_Dealloc. """
2000-04-21 18:15:05 -03:00
/* Entries 1 up to MAXSAVESIZE are free lists, entry 0 is the empty
tuple () of which at most one instance will be allocated.
*/
1997-05-02 00:12:38 -03:00
static PyTupleObject *free_tuples[MAXSAVESIZE];
Patch by Charles G Waldman to avoid a sneaky memory leak in _PyTuple_Resize(). In addition, a change suggested by Jeremy Hylton to limit the size of the free lists is also merged into this patch. Charles wrote initially: """ Test Case: run the following code: class Nothing: def __len__(self): return 5 def __getitem__(self, i): if i < 3: return i else: raise IndexError, i def g(a,*b,**c): return for x in xrange(1000000): g(*Nothing()) and watch Python's memory use go up and up. Diagnosis: The analysis begins with the call to PySequence_Tuple at line 1641 in ceval.c - the argument to g is seen to be a sequence but not a tuple, so it needs to be converted from an abstract sequence to a concrete tuple. PySequence_Tuple starts off by creating a new tuple of length 5 (line 1122 in abstract.c). Then at line 1149, since only 3 elements were assigned, _PyTuple_Resize is called to make the 5-tuple into a 3-tuple. When we're all done the 3-tuple is decrefed, but rather than being freed it is placed on the free_tuples cache. The basic problem is that the 3-tuples are being added to the cache but never picked up again, since _PyTuple_Resize doesn't make use of the free_tuples cache. If you are resizing a 5-tuple to a 3-tuple and there is already a 3-tuple in free_tuples[3], instead of using this tuple, _PyTuple_Resize will realloc the 5-tuple to a 3-tuple. It would more efficient to use the existing 3-tuple and cache the 5-tuple. By making _PyTuple_Resize aware of the free_tuples (just as PyTuple_New), we not only save a few calls to realloc, but also prevent this misbehavior whereby tuples are being added to the free_tuples list but never properly "recycled". """ And later: """ This patch replaces my submission of Sun, 16 Apr and addresses Jeremy Hylton's suggestions that we also limit the size of the free tuple list. I chose 2000 as the maximum number of tuples of any particular size to save. There was also a problem with the previous version of this patch causing a core dump if Python was built with Py_TRACE_REFS. This is fixed in the below version of the patch, which uses tupledealloc instead of _Py_Dealloc. """
2000-04-21 18:15:05 -03:00
static int num_free_tuples[MAXSAVESIZE];
#endif
#ifdef COUNT_ALLOCS
int fast_tuple_allocs;
int tuple_zero_allocs;
#endif
1997-05-02 00:12:38 -03:00
PyObject *
2000-07-09 04:04:36 -03:00
PyTuple_New(register int size)
1990-10-14 09:07:46 -03:00
{
register int i;
1997-05-02 00:12:38 -03:00
register PyTupleObject *op;
1990-10-14 09:07:46 -03:00
if (size < 0) {
1997-05-02 00:12:38 -03:00
PyErr_BadInternalCall();
1990-10-14 09:07:46 -03:00
return NULL;
}
#if MAXSAVESIZE > 0
if (size == 0 && free_tuples[0]) {
op = free_tuples[0];
1997-05-02 00:12:38 -03:00
Py_INCREF(op);
#ifdef COUNT_ALLOCS
tuple_zero_allocs++;
#endif
1997-05-02 00:12:38 -03:00
return (PyObject *) op;
}
1997-05-02 00:12:38 -03:00
if (0 < size && size < MAXSAVESIZE &&
(op = free_tuples[size]) != NULL)
{
free_tuples[size] = (PyTupleObject *) op->ob_item[0];
Patch by Charles G Waldman to avoid a sneaky memory leak in _PyTuple_Resize(). In addition, a change suggested by Jeremy Hylton to limit the size of the free lists is also merged into this patch. Charles wrote initially: """ Test Case: run the following code: class Nothing: def __len__(self): return 5 def __getitem__(self, i): if i < 3: return i else: raise IndexError, i def g(a,*b,**c): return for x in xrange(1000000): g(*Nothing()) and watch Python's memory use go up and up. Diagnosis: The analysis begins with the call to PySequence_Tuple at line 1641 in ceval.c - the argument to g is seen to be a sequence but not a tuple, so it needs to be converted from an abstract sequence to a concrete tuple. PySequence_Tuple starts off by creating a new tuple of length 5 (line 1122 in abstract.c). Then at line 1149, since only 3 elements were assigned, _PyTuple_Resize is called to make the 5-tuple into a 3-tuple. When we're all done the 3-tuple is decrefed, but rather than being freed it is placed on the free_tuples cache. The basic problem is that the 3-tuples are being added to the cache but never picked up again, since _PyTuple_Resize doesn't make use of the free_tuples cache. If you are resizing a 5-tuple to a 3-tuple and there is already a 3-tuple in free_tuples[3], instead of using this tuple, _PyTuple_Resize will realloc the 5-tuple to a 3-tuple. It would more efficient to use the existing 3-tuple and cache the 5-tuple. By making _PyTuple_Resize aware of the free_tuples (just as PyTuple_New), we not only save a few calls to realloc, but also prevent this misbehavior whereby tuples are being added to the free_tuples list but never properly "recycled". """ And later: """ This patch replaces my submission of Sun, 16 Apr and addresses Jeremy Hylton's suggestions that we also limit the size of the free tuple list. I chose 2000 as the maximum number of tuples of any particular size to save. There was also a problem with the previous version of this patch causing a core dump if Python was built with Py_TRACE_REFS. This is fixed in the below version of the patch, which uses tupledealloc instead of _Py_Dealloc. """
2000-04-21 18:15:05 -03:00
num_free_tuples[size]--;
#ifdef COUNT_ALLOCS
fast_tuple_allocs++;
#endif
/* PyObject_InitVar is inlined */
#ifdef Py_TRACE_REFS
op->ob_size = size;
op->ob_type = &PyTuple_Type;
#endif
_Py_NewReference((PyObject *)op);
}
else
#endif
{
int nbytes = size * sizeof(PyObject *);
/* Check for overflow */
if (nbytes / sizeof(PyObject *) != (size_t)size ||
(nbytes += sizeof(PyTupleObject) - sizeof(PyObject *)
+ PyGC_HEAD_SIZE)
<= 0)
{
return PyErr_NoMemory();
}
/* PyObject_NewVar is inlined */
op = (PyTupleObject *) PyObject_MALLOC(nbytes);
if (op == NULL)
1997-05-02 00:12:38 -03:00
return PyErr_NoMemory();
op = (PyTupleObject *) PyObject_FROM_GC(op);
PyObject_INIT_VAR(op, &PyTuple_Type, size);
}
1990-10-14 09:07:46 -03:00
for (i = 0; i < size; i++)
op->ob_item[i] = NULL;
#if MAXSAVESIZE > 0
if (size == 0) {
free_tuples[0] = op;
Patch by Charles G Waldman to avoid a sneaky memory leak in _PyTuple_Resize(). In addition, a change suggested by Jeremy Hylton to limit the size of the free lists is also merged into this patch. Charles wrote initially: """ Test Case: run the following code: class Nothing: def __len__(self): return 5 def __getitem__(self, i): if i < 3: return i else: raise IndexError, i def g(a,*b,**c): return for x in xrange(1000000): g(*Nothing()) and watch Python's memory use go up and up. Diagnosis: The analysis begins with the call to PySequence_Tuple at line 1641 in ceval.c - the argument to g is seen to be a sequence but not a tuple, so it needs to be converted from an abstract sequence to a concrete tuple. PySequence_Tuple starts off by creating a new tuple of length 5 (line 1122 in abstract.c). Then at line 1149, since only 3 elements were assigned, _PyTuple_Resize is called to make the 5-tuple into a 3-tuple. When we're all done the 3-tuple is decrefed, but rather than being freed it is placed on the free_tuples cache. The basic problem is that the 3-tuples are being added to the cache but never picked up again, since _PyTuple_Resize doesn't make use of the free_tuples cache. If you are resizing a 5-tuple to a 3-tuple and there is already a 3-tuple in free_tuples[3], instead of using this tuple, _PyTuple_Resize will realloc the 5-tuple to a 3-tuple. It would more efficient to use the existing 3-tuple and cache the 5-tuple. By making _PyTuple_Resize aware of the free_tuples (just as PyTuple_New), we not only save a few calls to realloc, but also prevent this misbehavior whereby tuples are being added to the free_tuples list but never properly "recycled". """ And later: """ This patch replaces my submission of Sun, 16 Apr and addresses Jeremy Hylton's suggestions that we also limit the size of the free tuple list. I chose 2000 as the maximum number of tuples of any particular size to save. There was also a problem with the previous version of this patch causing a core dump if Python was built with Py_TRACE_REFS. This is fixed in the below version of the patch, which uses tupledealloc instead of _Py_Dealloc. """
2000-04-21 18:15:05 -03:00
++num_free_tuples[0];
1997-05-02 00:12:38 -03:00
Py_INCREF(op); /* extra INCREF so that this is never freed */
}
#endif
PyObject_GC_Init(op);
1997-05-02 00:12:38 -03:00
return (PyObject *) op;
1990-10-14 09:07:46 -03:00
}
int
2000-07-09 04:04:36 -03:00
PyTuple_Size(register PyObject *op)
1990-10-14 09:07:46 -03:00
{
1997-05-02 00:12:38 -03:00
if (!PyTuple_Check(op)) {
PyErr_BadInternalCall();
1990-10-14 09:07:46 -03:00
return -1;
}
else
1997-05-02 00:12:38 -03:00
return ((PyTupleObject *)op)->ob_size;
1990-10-14 09:07:46 -03:00
}
1997-05-02 00:12:38 -03:00
PyObject *
2000-07-09 04:04:36 -03:00
PyTuple_GetItem(register PyObject *op, register int i)
1990-10-14 09:07:46 -03:00
{
1997-05-02 00:12:38 -03:00
if (!PyTuple_Check(op)) {
PyErr_BadInternalCall();
1990-10-14 09:07:46 -03:00
return NULL;
}
1997-05-02 00:12:38 -03:00
if (i < 0 || i >= ((PyTupleObject *)op) -> ob_size) {
PyErr_SetString(PyExc_IndexError, "tuple index out of range");
1990-10-14 09:07:46 -03:00
return NULL;
}
1997-05-02 00:12:38 -03:00
return ((PyTupleObject *)op) -> ob_item[i];
1990-10-14 09:07:46 -03:00
}
int
2000-07-09 04:04:36 -03:00
PyTuple_SetItem(register PyObject *op, register int i, PyObject *newitem)
1990-10-14 09:07:46 -03:00
{
1997-05-02 00:12:38 -03:00
register PyObject *olditem;
register PyObject **p;
if (!PyTuple_Check(op) || op->ob_refcnt != 1) {
1997-05-02 00:12:38 -03:00
Py_XDECREF(newitem);
PyErr_BadInternalCall();
1990-10-21 19:15:08 -03:00
return -1;
1990-10-14 09:07:46 -03:00
}
1997-05-02 00:12:38 -03:00
if (i < 0 || i >= ((PyTupleObject *)op) -> ob_size) {
Py_XDECREF(newitem);
PyErr_SetString(PyExc_IndexError,
"tuple assignment index out of range");
1990-10-21 19:15:08 -03:00
return -1;
1990-10-14 09:07:46 -03:00
}
1997-05-02 00:12:38 -03:00
p = ((PyTupleObject *)op) -> ob_item + i;
1995-03-09 08:12:50 -04:00
olditem = *p;
*p = newitem;
1997-05-02 00:12:38 -03:00
Py_XDECREF(olditem);
1990-10-14 09:07:46 -03:00
return 0;
}
/* Methods */
static void
2000-07-09 04:04:36 -03:00
tupledealloc(register PyTupleObject *op)
1990-10-14 09:07:46 -03:00
{
register int i;
Patch by Charles G Waldman to avoid a sneaky memory leak in _PyTuple_Resize(). In addition, a change suggested by Jeremy Hylton to limit the size of the free lists is also merged into this patch. Charles wrote initially: """ Test Case: run the following code: class Nothing: def __len__(self): return 5 def __getitem__(self, i): if i < 3: return i else: raise IndexError, i def g(a,*b,**c): return for x in xrange(1000000): g(*Nothing()) and watch Python's memory use go up and up. Diagnosis: The analysis begins with the call to PySequence_Tuple at line 1641 in ceval.c - the argument to g is seen to be a sequence but not a tuple, so it needs to be converted from an abstract sequence to a concrete tuple. PySequence_Tuple starts off by creating a new tuple of length 5 (line 1122 in abstract.c). Then at line 1149, since only 3 elements were assigned, _PyTuple_Resize is called to make the 5-tuple into a 3-tuple. When we're all done the 3-tuple is decrefed, but rather than being freed it is placed on the free_tuples cache. The basic problem is that the 3-tuples are being added to the cache but never picked up again, since _PyTuple_Resize doesn't make use of the free_tuples cache. If you are resizing a 5-tuple to a 3-tuple and there is already a 3-tuple in free_tuples[3], instead of using this tuple, _PyTuple_Resize will realloc the 5-tuple to a 3-tuple. It would more efficient to use the existing 3-tuple and cache the 5-tuple. By making _PyTuple_Resize aware of the free_tuples (just as PyTuple_New), we not only save a few calls to realloc, but also prevent this misbehavior whereby tuples are being added to the free_tuples list but never properly "recycled". """ And later: """ This patch replaces my submission of Sun, 16 Apr and addresses Jeremy Hylton's suggestions that we also limit the size of the free tuple list. I chose 2000 as the maximum number of tuples of any particular size to save. There was also a problem with the previous version of this patch causing a core dump if Python was built with Py_TRACE_REFS. This is fixed in the below version of the patch, which uses tupledealloc instead of _Py_Dealloc. """
2000-04-21 18:15:05 -03:00
register int len = op->ob_size;
Py_TRASHCAN_SAFE_BEGIN(op)
PyObject_GC_Fini(op);
Patch by Charles G Waldman to avoid a sneaky memory leak in _PyTuple_Resize(). In addition, a change suggested by Jeremy Hylton to limit the size of the free lists is also merged into this patch. Charles wrote initially: """ Test Case: run the following code: class Nothing: def __len__(self): return 5 def __getitem__(self, i): if i < 3: return i else: raise IndexError, i def g(a,*b,**c): return for x in xrange(1000000): g(*Nothing()) and watch Python's memory use go up and up. Diagnosis: The analysis begins with the call to PySequence_Tuple at line 1641 in ceval.c - the argument to g is seen to be a sequence but not a tuple, so it needs to be converted from an abstract sequence to a concrete tuple. PySequence_Tuple starts off by creating a new tuple of length 5 (line 1122 in abstract.c). Then at line 1149, since only 3 elements were assigned, _PyTuple_Resize is called to make the 5-tuple into a 3-tuple. When we're all done the 3-tuple is decrefed, but rather than being freed it is placed on the free_tuples cache. The basic problem is that the 3-tuples are being added to the cache but never picked up again, since _PyTuple_Resize doesn't make use of the free_tuples cache. If you are resizing a 5-tuple to a 3-tuple and there is already a 3-tuple in free_tuples[3], instead of using this tuple, _PyTuple_Resize will realloc the 5-tuple to a 3-tuple. It would more efficient to use the existing 3-tuple and cache the 5-tuple. By making _PyTuple_Resize aware of the free_tuples (just as PyTuple_New), we not only save a few calls to realloc, but also prevent this misbehavior whereby tuples are being added to the free_tuples list but never properly "recycled". """ And later: """ This patch replaces my submission of Sun, 16 Apr and addresses Jeremy Hylton's suggestions that we also limit the size of the free tuple list. I chose 2000 as the maximum number of tuples of any particular size to save. There was also a problem with the previous version of this patch causing a core dump if Python was built with Py_TRACE_REFS. This is fixed in the below version of the patch, which uses tupledealloc instead of _Py_Dealloc. """
2000-04-21 18:15:05 -03:00
if (len > 0) {
i = len;
while (--i >= 0)
Py_XDECREF(op->ob_item[i]);
#if MAXSAVESIZE > 0
Patch by Charles G Waldman to avoid a sneaky memory leak in _PyTuple_Resize(). In addition, a change suggested by Jeremy Hylton to limit the size of the free lists is also merged into this patch. Charles wrote initially: """ Test Case: run the following code: class Nothing: def __len__(self): return 5 def __getitem__(self, i): if i < 3: return i else: raise IndexError, i def g(a,*b,**c): return for x in xrange(1000000): g(*Nothing()) and watch Python's memory use go up and up. Diagnosis: The analysis begins with the call to PySequence_Tuple at line 1641 in ceval.c - the argument to g is seen to be a sequence but not a tuple, so it needs to be converted from an abstract sequence to a concrete tuple. PySequence_Tuple starts off by creating a new tuple of length 5 (line 1122 in abstract.c). Then at line 1149, since only 3 elements were assigned, _PyTuple_Resize is called to make the 5-tuple into a 3-tuple. When we're all done the 3-tuple is decrefed, but rather than being freed it is placed on the free_tuples cache. The basic problem is that the 3-tuples are being added to the cache but never picked up again, since _PyTuple_Resize doesn't make use of the free_tuples cache. If you are resizing a 5-tuple to a 3-tuple and there is already a 3-tuple in free_tuples[3], instead of using this tuple, _PyTuple_Resize will realloc the 5-tuple to a 3-tuple. It would more efficient to use the existing 3-tuple and cache the 5-tuple. By making _PyTuple_Resize aware of the free_tuples (just as PyTuple_New), we not only save a few calls to realloc, but also prevent this misbehavior whereby tuples are being added to the free_tuples list but never properly "recycled". """ And later: """ This patch replaces my submission of Sun, 16 Apr and addresses Jeremy Hylton's suggestions that we also limit the size of the free tuple list. I chose 2000 as the maximum number of tuples of any particular size to save. There was also a problem with the previous version of this patch causing a core dump if Python was built with Py_TRACE_REFS. This is fixed in the below version of the patch, which uses tupledealloc instead of _Py_Dealloc. """
2000-04-21 18:15:05 -03:00
if (len < MAXSAVESIZE && num_free_tuples[len] < MAXSAVEDTUPLES) {
op->ob_item[0] = (PyObject *) free_tuples[len];
num_free_tuples[len]++;
free_tuples[len] = op;
goto done; /* return */
}
#endif
}
2000-06-30 22:00:38 -03:00
op = (PyTupleObject *) PyObject_AS_GC(op);
PyObject_DEL(op);
done:
Py_TRASHCAN_SAFE_END(op)
1990-10-14 09:07:46 -03:00
}
static int
2000-07-09 04:04:36 -03:00
tupleprint(PyTupleObject *op, FILE *fp, int flags)
1990-10-14 09:07:46 -03:00
{
int i;
fprintf(fp, "(");
for (i = 0; i < op->ob_size; i++) {
if (i > 0)
1990-10-14 09:07:46 -03:00
fprintf(fp, ", ");
1997-05-02 00:12:38 -03:00
if (PyObject_Print(op->ob_item[i], fp, 0) != 0)
return -1;
1990-10-14 09:07:46 -03:00
}
if (op->ob_size == 1)
fprintf(fp, ",");
fprintf(fp, ")");
return 0;
1990-10-14 09:07:46 -03:00
}
1997-05-02 00:12:38 -03:00
static PyObject *
2000-07-09 04:04:36 -03:00
tuplerepr(PyTupleObject *v)
1990-10-14 09:07:46 -03:00
{
1997-05-02 00:12:38 -03:00
PyObject *s, *comma;
1990-10-14 09:07:46 -03:00
int i;
1997-05-02 00:12:38 -03:00
s = PyString_FromString("(");
comma = PyString_FromString(", ");
1990-10-14 09:07:46 -03:00
for (i = 0; i < v->ob_size && s != NULL; i++) {
if (i > 0)
1997-05-02 00:12:38 -03:00
PyString_Concat(&s, comma);
PyString_ConcatAndDel(&s, PyObject_Repr(v->ob_item[i]));
1990-10-14 09:07:46 -03:00
}
1997-05-02 00:12:38 -03:00
Py_DECREF(comma);
1994-08-30 05:27:36 -03:00
if (v->ob_size == 1)
1997-05-02 00:12:38 -03:00
PyString_ConcatAndDel(&s, PyString_FromString(","));
PyString_ConcatAndDel(&s, PyString_FromString(")"));
1990-10-14 09:07:46 -03:00
return s;
}
static int
2000-07-09 04:04:36 -03:00
tuplecompare(register PyTupleObject *v, register PyTupleObject *w)
1990-10-14 09:07:46 -03:00
{
register int len =
(v->ob_size < w->ob_size) ? v->ob_size : w->ob_size;
register int i;
for (i = 0; i < len; i++) {
1997-05-02 00:12:38 -03:00
int cmp = PyObject_Compare(v->ob_item[i], w->ob_item[i]);
1990-10-14 09:07:46 -03:00
if (cmp != 0)
return cmp;
}
return v->ob_size - w->ob_size;
}
static long
2000-07-09 04:04:36 -03:00
tuplehash(PyTupleObject *v)
{
register long x, y;
register int len = v->ob_size;
1997-05-02 00:12:38 -03:00
register PyObject **p;
x = 0x345678L;
p = v->ob_item;
while (--len >= 0) {
1997-05-02 00:12:38 -03:00
y = PyObject_Hash(*p++);
if (y == -1)
return -1;
1996-12-16 13:55:46 -04:00
x = (1000003*x) ^ y;
}
x ^= v->ob_size;
if (x == -1)
x = -2;
return x;
}
1990-10-14 09:07:46 -03:00
static int
2000-07-09 04:04:36 -03:00
tuplelength(PyTupleObject *a)
1990-10-14 09:07:46 -03:00
{
return a->ob_size;
}
static int
2000-07-09 04:04:36 -03:00
tuplecontains(PyTupleObject *a, PyObject *el)
{
int i, cmp;
for (i = 0; i < a->ob_size; ++i) {
cmp = PyObject_Compare(el, PyTuple_GET_ITEM(a, i));
if (cmp == 0)
return 1;
if (PyErr_Occurred())
return -1;
}
return 0;
}
1997-05-02 00:12:38 -03:00
static PyObject *
2000-07-09 04:04:36 -03:00
tupleitem(register PyTupleObject *a, register int i)
1990-10-14 09:07:46 -03:00
{
if (i < 0 || i >= a->ob_size) {
1997-05-02 00:12:38 -03:00
PyErr_SetString(PyExc_IndexError, "tuple index out of range");
1990-10-14 09:07:46 -03:00
return NULL;
}
1997-05-02 00:12:38 -03:00
Py_INCREF(a->ob_item[i]);
1990-10-14 09:07:46 -03:00
return a->ob_item[i];
}
1997-05-02 00:12:38 -03:00
static PyObject *
2000-07-09 04:04:36 -03:00
tupleslice(register PyTupleObject *a, register int ilow, register int ihigh)
1990-10-14 09:07:46 -03:00
{
1997-05-02 00:12:38 -03:00
register PyTupleObject *np;
1990-10-14 09:07:46 -03:00
register int i;
if (ilow < 0)
ilow = 0;
if (ihigh > a->ob_size)
ihigh = a->ob_size;
if (ihigh < ilow)
ihigh = ilow;
if (ilow == 0 && ihigh == a->ob_size) {
/* XXX can only do this if tuples are immutable! */
1997-05-02 00:12:38 -03:00
Py_INCREF(a);
return (PyObject *)a;
1990-10-14 09:07:46 -03:00
}
1997-05-02 00:12:38 -03:00
np = (PyTupleObject *)PyTuple_New(ihigh - ilow);
1990-10-14 09:07:46 -03:00
if (np == NULL)
return NULL;
for (i = ilow; i < ihigh; i++) {
1997-05-02 00:12:38 -03:00
PyObject *v = a->ob_item[i];
Py_INCREF(v);
1990-10-14 09:07:46 -03:00
np->ob_item[i - ilow] = v;
}
1997-05-02 00:12:38 -03:00
return (PyObject *)np;
1990-10-14 09:07:46 -03:00
}
1997-05-02 00:12:38 -03:00
PyObject *
2000-07-09 04:04:36 -03:00
PyTuple_GetSlice(PyObject *op, int i, int j)
1992-01-14 14:45:33 -04:00
{
1997-05-02 00:12:38 -03:00
if (op == NULL || !PyTuple_Check(op)) {
PyErr_BadInternalCall();
1992-01-14 14:45:33 -04:00
return NULL;
}
1997-05-02 00:12:38 -03:00
return tupleslice((PyTupleObject *)op, i, j);
1992-01-14 14:45:33 -04:00
}
1997-05-02 00:12:38 -03:00
static PyObject *
2000-07-09 04:04:36 -03:00
tupleconcat(register PyTupleObject *a, register PyObject *bb)
1990-10-14 09:07:46 -03:00
{
register int size;
register int i;
1997-05-02 00:12:38 -03:00
PyTupleObject *np;
if (!PyTuple_Check(bb)) {
PyErr_Format(PyExc_TypeError,
"can only concatenate tuple (not \"%.200s\") to tuple",
bb->ob_type->tp_name);
1990-10-14 09:07:46 -03:00
return NULL;
}
1997-05-02 00:12:38 -03:00
#define b ((PyTupleObject *)bb)
1990-10-14 09:07:46 -03:00
size = a->ob_size + b->ob_size;
1997-05-02 00:12:38 -03:00
np = (PyTupleObject *) PyTuple_New(size);
1990-10-14 09:07:46 -03:00
if (np == NULL) {
return NULL;
1990-10-14 09:07:46 -03:00
}
for (i = 0; i < a->ob_size; i++) {
1997-05-02 00:12:38 -03:00
PyObject *v = a->ob_item[i];
Py_INCREF(v);
1990-10-14 09:07:46 -03:00
np->ob_item[i] = v;
}
for (i = 0; i < b->ob_size; i++) {
1997-05-02 00:12:38 -03:00
PyObject *v = b->ob_item[i];
Py_INCREF(v);
1990-10-14 09:07:46 -03:00
np->ob_item[i + a->ob_size] = v;
}
1997-05-02 00:12:38 -03:00
return (PyObject *)np;
1990-10-14 09:07:46 -03:00
#undef b
}
1997-05-02 00:12:38 -03:00
static PyObject *
2000-07-09 04:04:36 -03:00
tuplerepeat(PyTupleObject *a, int n)
{
int i, j;
int size;
1997-05-02 00:12:38 -03:00
PyTupleObject *np;
PyObject **p;
if (n < 0)
n = 0;
if (a->ob_size == 0 || n == 1) {
/* Since tuples are immutable, we can return a shared
copy in this case */
1997-05-02 00:12:38 -03:00
Py_INCREF(a);
return (PyObject *)a;
}
size = a->ob_size * n;
if (size/a->ob_size != n)
return PyErr_NoMemory();
1997-05-02 00:12:38 -03:00
np = (PyTupleObject *) PyTuple_New(size);
if (np == NULL)
return NULL;
p = np->ob_item;
for (i = 0; i < n; i++) {
for (j = 0; j < a->ob_size; j++) {
*p = a->ob_item[j];
1997-05-02 00:12:38 -03:00
Py_INCREF(*p);
p++;
}
}
1997-05-02 00:12:38 -03:00
return (PyObject *) np;
}
static int
tupletraverse(PyTupleObject *o, visitproc visit, void *arg)
{
int i, err;
PyObject *x;
for (i = o->ob_size; --i >= 0; ) {
x = o->ob_item[i];
if (x != NULL) {
err = visit(x, arg);
if (err)
return err;
}
}
return 0;
}
1997-05-02 00:12:38 -03:00
static PySequenceMethods tuple_as_sequence = {
1994-08-30 05:27:36 -03:00
(inquiry)tuplelength, /*sq_length*/
(binaryfunc)tupleconcat, /*sq_concat*/
(intargfunc)tuplerepeat, /*sq_repeat*/
(intargfunc)tupleitem, /*sq_item*/
(intintargfunc)tupleslice, /*sq_slice*/
1990-10-14 09:07:46 -03:00
0, /*sq_ass_item*/
0, /*sq_ass_slice*/
(objobjproc)tuplecontains, /*sq_contains*/
1990-10-14 09:07:46 -03:00
};
1997-05-02 00:12:38 -03:00
PyTypeObject PyTuple_Type = {
PyObject_HEAD_INIT(&PyType_Type)
1990-10-14 09:07:46 -03:00
0,
"tuple",
sizeof(PyTupleObject) - sizeof(PyObject *) + PyGC_HEAD_SIZE,
1997-05-02 00:12:38 -03:00
sizeof(PyObject *),
1994-08-30 05:27:36 -03:00
(destructor)tupledealloc, /*tp_dealloc*/
(printfunc)tupleprint, /*tp_print*/
1990-10-14 09:07:46 -03:00
0, /*tp_getattr*/
0, /*tp_setattr*/
1994-08-30 05:27:36 -03:00
(cmpfunc)tuplecompare, /*tp_compare*/
(reprfunc)tuplerepr, /*tp_repr*/
1990-10-14 09:07:46 -03:00
0, /*tp_as_number*/
&tuple_as_sequence, /*tp_as_sequence*/
0, /*tp_as_mapping*/
1994-08-30 05:27:36 -03:00
(hashfunc)tuplehash, /*tp_hash*/
0, /*tp_call*/
0, /*tp_str*/
0, /*tp_getattro*/
0, /*tp_setattro*/
0, /*tp_as_buffer*/
Py_TPFLAGS_DEFAULT | Py_TPFLAGS_GC, /*tp_flags*/
0, /*tp_doc*/
(traverseproc)tupletraverse, /* tp_traverse */
1990-10-14 09:07:46 -03:00
};
/* The following function breaks the notion that tuples are immutable:
it changes the size of a tuple. We get away with this only if there
is only one module referencing the object. You can also think of it
as creating a new tuple object and destroying the old one, only
more efficiently. In any case, don't use this if the tuple may
already be known to some other part of the code...
If last_is_sticky is set, the tuple will grow or shrink at the
front, otherwise it will grow or shrink at the end. */
int
2000-07-09 04:04:36 -03:00
_PyTuple_Resize(PyObject **pv, int newsize, int last_is_sticky)
{
1997-05-02 00:12:38 -03:00
register PyTupleObject *v;
register PyTupleObject *sv;
int i;
int sizediff;
1997-05-02 00:12:38 -03:00
v = (PyTupleObject *) *pv;
if (v == NULL || !PyTuple_Check(v) || v->ob_refcnt != 1) {
*pv = 0;
1997-05-02 00:12:38 -03:00
Py_DECREF(v);
PyErr_BadInternalCall();
return -1;
}
1995-08-04 01:05:10 -03:00
sizediff = newsize - v->ob_size;
if (sizediff == 0)
return 0;
/* XXX UNREF/NEWREF interface should be more symmetrical */
1996-05-23 19:46:51 -03:00
#ifdef Py_REF_DEBUG
1995-03-29 12:57:48 -04:00
--_Py_RefTotal;
#endif
_Py_ForgetReference((PyObject *)v);
if (last_is_sticky && sizediff < 0) {
1997-05-02 00:12:38 -03:00
/* shrinking:
move entries to the front and zero moved entries */
for (i = 0; i < newsize; i++) {
1997-05-02 00:12:38 -03:00
Py_XDECREF(v->ob_item[i]);
v->ob_item[i] = v->ob_item[i - sizediff];
v->ob_item[i - sizediff] = NULL;
}
}
for (i = newsize; i < v->ob_size; i++) {
1997-05-02 00:12:38 -03:00
Py_XDECREF(v->ob_item[i]);
v->ob_item[i] = NULL;
}
Patch by Charles G Waldman to avoid a sneaky memory leak in _PyTuple_Resize(). In addition, a change suggested by Jeremy Hylton to limit the size of the free lists is also merged into this patch. Charles wrote initially: """ Test Case: run the following code: class Nothing: def __len__(self): return 5 def __getitem__(self, i): if i < 3: return i else: raise IndexError, i def g(a,*b,**c): return for x in xrange(1000000): g(*Nothing()) and watch Python's memory use go up and up. Diagnosis: The analysis begins with the call to PySequence_Tuple at line 1641 in ceval.c - the argument to g is seen to be a sequence but not a tuple, so it needs to be converted from an abstract sequence to a concrete tuple. PySequence_Tuple starts off by creating a new tuple of length 5 (line 1122 in abstract.c). Then at line 1149, since only 3 elements were assigned, _PyTuple_Resize is called to make the 5-tuple into a 3-tuple. When we're all done the 3-tuple is decrefed, but rather than being freed it is placed on the free_tuples cache. The basic problem is that the 3-tuples are being added to the cache but never picked up again, since _PyTuple_Resize doesn't make use of the free_tuples cache. If you are resizing a 5-tuple to a 3-tuple and there is already a 3-tuple in free_tuples[3], instead of using this tuple, _PyTuple_Resize will realloc the 5-tuple to a 3-tuple. It would more efficient to use the existing 3-tuple and cache the 5-tuple. By making _PyTuple_Resize aware of the free_tuples (just as PyTuple_New), we not only save a few calls to realloc, but also prevent this misbehavior whereby tuples are being added to the free_tuples list but never properly "recycled". """ And later: """ This patch replaces my submission of Sun, 16 Apr and addresses Jeremy Hylton's suggestions that we also limit the size of the free tuple list. I chose 2000 as the maximum number of tuples of any particular size to save. There was also a problem with the previous version of this patch causing a core dump if Python was built with Py_TRACE_REFS. This is fixed in the below version of the patch, which uses tupledealloc instead of _Py_Dealloc. """
2000-04-21 18:15:05 -03:00
#if MAXSAVESIZE > 0
if (newsize == 0 && free_tuples[0]) {
num_free_tuples[0]--;
sv = free_tuples[0];
sv->ob_size = 0;
Py_INCREF(sv);
#ifdef COUNT_ALLOCS
tuple_zero_allocs++;
#endif
tupledealloc(v);
*pv = (PyObject*) sv;
return 0;
}
if (0 < newsize && newsize < MAXSAVESIZE &&
(sv = free_tuples[newsize]) != NULL)
{
free_tuples[newsize] = (PyTupleObject *) sv->ob_item[0];
num_free_tuples[newsize]--;
#ifdef COUNT_ALLOCS
fast_tuple_allocs++;
#endif
#ifdef Py_TRACE_REFS
sv->ob_type = &PyTuple_Type;
#endif
for (i = 0; i < newsize; ++i){
sv->ob_item[i] = v->ob_item[i];
v->ob_item[i] = NULL;
}
sv->ob_size = v->ob_size;
tupledealloc(v);
*pv = (PyObject *) sv;
} else
#endif
{
#ifdef WITH_CYCLE_GC
PyGC_Head *g = PyObject_AS_GC((PyObject *)v);
PyObject_GC_Fini((PyObject *)v);
sv = (PyTupleObject *)
PyObject_REALLOC((char *)g, sizeof(PyTupleObject)
+ PyGC_HEAD_SIZE
+ newsize * sizeof(PyObject *));
if (g == NULL) {
sv = NULL;
} else {
sv = (PyTupleObject *)PyObject_FROM_GC(g);
}
#else
Patch by Charles G Waldman to avoid a sneaky memory leak in _PyTuple_Resize(). In addition, a change suggested by Jeremy Hylton to limit the size of the free lists is also merged into this patch. Charles wrote initially: """ Test Case: run the following code: class Nothing: def __len__(self): return 5 def __getitem__(self, i): if i < 3: return i else: raise IndexError, i def g(a,*b,**c): return for x in xrange(1000000): g(*Nothing()) and watch Python's memory use go up and up. Diagnosis: The analysis begins with the call to PySequence_Tuple at line 1641 in ceval.c - the argument to g is seen to be a sequence but not a tuple, so it needs to be converted from an abstract sequence to a concrete tuple. PySequence_Tuple starts off by creating a new tuple of length 5 (line 1122 in abstract.c). Then at line 1149, since only 3 elements were assigned, _PyTuple_Resize is called to make the 5-tuple into a 3-tuple. When we're all done the 3-tuple is decrefed, but rather than being freed it is placed on the free_tuples cache. The basic problem is that the 3-tuples are being added to the cache but never picked up again, since _PyTuple_Resize doesn't make use of the free_tuples cache. If you are resizing a 5-tuple to a 3-tuple and there is already a 3-tuple in free_tuples[3], instead of using this tuple, _PyTuple_Resize will realloc the 5-tuple to a 3-tuple. It would more efficient to use the existing 3-tuple and cache the 5-tuple. By making _PyTuple_Resize aware of the free_tuples (just as PyTuple_New), we not only save a few calls to realloc, but also prevent this misbehavior whereby tuples are being added to the free_tuples list but never properly "recycled". """ And later: """ This patch replaces my submission of Sun, 16 Apr and addresses Jeremy Hylton's suggestions that we also limit the size of the free tuple list. I chose 2000 as the maximum number of tuples of any particular size to save. There was also a problem with the previous version of this patch causing a core dump if Python was built with Py_TRACE_REFS. This is fixed in the below version of the patch, which uses tupledealloc instead of _Py_Dealloc. """
2000-04-21 18:15:05 -03:00
sv = (PyTupleObject *)
PyObject_REALLOC((char *)v, sizeof(PyTupleObject)
+ PyGC_HEAD_SIZE
+ newsize * sizeof(PyObject *));
#endif
Patch by Charles G Waldman to avoid a sneaky memory leak in _PyTuple_Resize(). In addition, a change suggested by Jeremy Hylton to limit the size of the free lists is also merged into this patch. Charles wrote initially: """ Test Case: run the following code: class Nothing: def __len__(self): return 5 def __getitem__(self, i): if i < 3: return i else: raise IndexError, i def g(a,*b,**c): return for x in xrange(1000000): g(*Nothing()) and watch Python's memory use go up and up. Diagnosis: The analysis begins with the call to PySequence_Tuple at line 1641 in ceval.c - the argument to g is seen to be a sequence but not a tuple, so it needs to be converted from an abstract sequence to a concrete tuple. PySequence_Tuple starts off by creating a new tuple of length 5 (line 1122 in abstract.c). Then at line 1149, since only 3 elements were assigned, _PyTuple_Resize is called to make the 5-tuple into a 3-tuple. When we're all done the 3-tuple is decrefed, but rather than being freed it is placed on the free_tuples cache. The basic problem is that the 3-tuples are being added to the cache but never picked up again, since _PyTuple_Resize doesn't make use of the free_tuples cache. If you are resizing a 5-tuple to a 3-tuple and there is already a 3-tuple in free_tuples[3], instead of using this tuple, _PyTuple_Resize will realloc the 5-tuple to a 3-tuple. It would more efficient to use the existing 3-tuple and cache the 5-tuple. By making _PyTuple_Resize aware of the free_tuples (just as PyTuple_New), we not only save a few calls to realloc, but also prevent this misbehavior whereby tuples are being added to the free_tuples list but never properly "recycled". """ And later: """ This patch replaces my submission of Sun, 16 Apr and addresses Jeremy Hylton's suggestions that we also limit the size of the free tuple list. I chose 2000 as the maximum number of tuples of any particular size to save. There was also a problem with the previous version of this patch causing a core dump if Python was built with Py_TRACE_REFS. This is fixed in the below version of the patch, which uses tupledealloc instead of _Py_Dealloc. """
2000-04-21 18:15:05 -03:00
*pv = (PyObject *) sv;
if (sv == NULL) {
PyObject_GC_Init((PyObject *)v);
2000-06-30 22:00:38 -03:00
v = (PyTupleObject *) PyObject_AS_GC(v);
PyObject_DEL(v);
Patch by Charles G Waldman to avoid a sneaky memory leak in _PyTuple_Resize(). In addition, a change suggested by Jeremy Hylton to limit the size of the free lists is also merged into this patch. Charles wrote initially: """ Test Case: run the following code: class Nothing: def __len__(self): return 5 def __getitem__(self, i): if i < 3: return i else: raise IndexError, i def g(a,*b,**c): return for x in xrange(1000000): g(*Nothing()) and watch Python's memory use go up and up. Diagnosis: The analysis begins with the call to PySequence_Tuple at line 1641 in ceval.c - the argument to g is seen to be a sequence but not a tuple, so it needs to be converted from an abstract sequence to a concrete tuple. PySequence_Tuple starts off by creating a new tuple of length 5 (line 1122 in abstract.c). Then at line 1149, since only 3 elements were assigned, _PyTuple_Resize is called to make the 5-tuple into a 3-tuple. When we're all done the 3-tuple is decrefed, but rather than being freed it is placed on the free_tuples cache. The basic problem is that the 3-tuples are being added to the cache but never picked up again, since _PyTuple_Resize doesn't make use of the free_tuples cache. If you are resizing a 5-tuple to a 3-tuple and there is already a 3-tuple in free_tuples[3], instead of using this tuple, _PyTuple_Resize will realloc the 5-tuple to a 3-tuple. It would more efficient to use the existing 3-tuple and cache the 5-tuple. By making _PyTuple_Resize aware of the free_tuples (just as PyTuple_New), we not only save a few calls to realloc, but also prevent this misbehavior whereby tuples are being added to the free_tuples list but never properly "recycled". """ And later: """ This patch replaces my submission of Sun, 16 Apr and addresses Jeremy Hylton's suggestions that we also limit the size of the free tuple list. I chose 2000 as the maximum number of tuples of any particular size to save. There was also a problem with the previous version of this patch causing a core dump if Python was built with Py_TRACE_REFS. This is fixed in the below version of the patch, which uses tupledealloc instead of _Py_Dealloc. """
2000-04-21 18:15:05 -03:00
PyErr_NoMemory();
return -1;
}
}
_Py_NewReference((PyObject *)sv);
for (i = sv->ob_size; i < newsize; i++)
sv->ob_item[i] = NULL;
if (last_is_sticky && sizediff > 0) {
/* growing: move entries to the end and zero moved entries */
for (i = newsize - 1; i >= sizediff; i--) {
sv->ob_item[i] = sv->ob_item[i - sizediff];
sv->ob_item[i - sizediff] = NULL;
}
}
PyObject_GC_Init(sv);
sv->ob_size = newsize;
return 0;
}
void
2000-07-09 04:04:36 -03:00
PyTuple_Fini(void)
{
#if MAXSAVESIZE > 0
int i;
Py_XDECREF(free_tuples[0]);
free_tuples[0] = NULL;
for (i = 1; i < MAXSAVESIZE; i++) {
PyTupleObject *p, *q;
p = free_tuples[i];
free_tuples[i] = NULL;
while (p) {
q = p;
p = (PyTupleObject *)(p->ob_item[0]);
2000-06-30 22:00:38 -03:00
q = (PyTupleObject *) PyObject_AS_GC(q);
PyObject_DEL(q);
}
}
#endif
}