2004-01-29 14:37:52 +08:00
|
|
|
#include "Python.h"
|
2004-05-30 15:26:47 +08:00
|
|
|
#include "structmember.h"
|
2004-01-29 14:37:52 +08:00
|
|
|
|
|
|
|
/* collections module implementation of a deque() datatype
|
|
|
|
Written and maintained by Raymond D. Hettinger <python@rcn.com>
|
|
|
|
Copyright (c) 2004 Python Software Foundation.
|
|
|
|
All rights reserved.
|
|
|
|
*/
|
|
|
|
|
2004-10-01 23:25:53 +08:00
|
|
|
/* The block length may be set to any number over 1. Larger numbers
|
|
|
|
* reduce the number of calls to the memory allocator but take more
|
|
|
|
* memory. Ideally, BLOCKLEN should be set with an eye to the
|
|
|
|
* length of a cache line.
|
|
|
|
*/
|
|
|
|
|
|
|
|
#define BLOCKLEN 46
|
2004-10-01 14:24:12 +08:00
|
|
|
#define CENTER ((BLOCKLEN - 1) / 2)
|
2004-01-29 14:37:52 +08:00
|
|
|
|
2004-10-01 09:32:53 +08:00
|
|
|
/* A `dequeobject` is composed of a doubly-linked list of `block` nodes.
|
|
|
|
* This list is not circular (the leftmost block has leftlink==NULL,
|
|
|
|
* and the rightmost block has rightlink==NULL). A deque d's first
|
|
|
|
* element is at d.leftblock[leftindex] and its last element is at
|
|
|
|
* d.rightblock[rightindex]; note that, unlike as for Python slice
|
2004-10-01 14:24:12 +08:00
|
|
|
* indices, these indices are inclusive on both ends. By being inclusive
|
|
|
|
* on both ends, algorithms for left and right operations become
|
|
|
|
* symmetrical which simplifies the design.
|
|
|
|
*
|
|
|
|
* The list of blocks is never empty, so d.leftblock and d.rightblock
|
|
|
|
* are never equal to NULL.
|
|
|
|
*
|
|
|
|
* The indices, d.leftindex and d.rightindex are always in the range
|
|
|
|
* 0 <= index < BLOCKLEN.
|
2004-10-01 23:14:39 +08:00
|
|
|
* Their exact relationship is:
|
|
|
|
* (d.leftindex + d.len - 1) % BLOCKLEN == d.rightindex.
|
2004-10-01 14:24:12 +08:00
|
|
|
*
|
|
|
|
* Empty deques have d.len == 0; d.leftblock==d.rightblock;
|
|
|
|
* d.leftindex == CENTER+1; and d.rightindex == CENTER.
|
|
|
|
* Checking for d.len == 0 is the intended way to see whether d is empty.
|
|
|
|
*
|
|
|
|
* Whenever d.leftblock == d.rightblock,
|
2004-10-01 23:14:39 +08:00
|
|
|
* d.leftindex + d.len - 1 == d.rightindex.
|
2004-10-01 14:24:12 +08:00
|
|
|
*
|
2004-10-01 23:14:39 +08:00
|
|
|
* However, when d.leftblock != d.rightblock, d.leftindex and d.rightindex
|
|
|
|
* become indices into distinct blocks and either may be larger than the
|
|
|
|
* other.
|
2004-10-01 09:32:53 +08:00
|
|
|
*/
|
|
|
|
|
2004-01-29 14:37:52 +08:00
|
|
|
typedef struct BLOCK {
|
|
|
|
struct BLOCK *leftlink;
|
|
|
|
struct BLOCK *rightlink;
|
|
|
|
PyObject *data[BLOCKLEN];
|
|
|
|
} block;
|
|
|
|
|
2004-10-01 09:04:50 +08:00
|
|
|
static block *
|
2004-10-07 01:51:54 +08:00
|
|
|
newblock(block *leftlink, block *rightlink, int len) {
|
|
|
|
block *b;
|
|
|
|
/* To prevent len from overflowing INT_MAX on 64-bit machines, we
|
|
|
|
* refuse to allocate new blocks if the current len is dangerously
|
|
|
|
* close. There is some extra margin to prevent spurious arithmetic
|
|
|
|
* overflows at various places. The following check ensures that
|
|
|
|
* the blocks allocated to the deque, in the worst case, can only
|
|
|
|
* have INT_MAX-2 entries in total.
|
|
|
|
*/
|
|
|
|
if (len >= INT_MAX - 2*BLOCKLEN) {
|
|
|
|
PyErr_SetString(PyExc_OverflowError,
|
|
|
|
"cannot add more blocks to the deque");
|
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
b = PyMem_Malloc(sizeof(block));
|
2004-01-29 14:37:52 +08:00
|
|
|
if (b == NULL) {
|
|
|
|
PyErr_NoMemory();
|
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
b->leftlink = leftlink;
|
|
|
|
b->rightlink = rightlink;
|
|
|
|
return b;
|
|
|
|
}
|
|
|
|
|
|
|
|
typedef struct {
|
|
|
|
PyObject_HEAD
|
|
|
|
block *leftblock;
|
|
|
|
block *rightblock;
|
2004-10-01 09:32:53 +08:00
|
|
|
int leftindex; /* in range(BLOCKLEN) */
|
|
|
|
int rightindex; /* in range(BLOCKLEN) */
|
2004-01-29 14:37:52 +08:00
|
|
|
int len;
|
2004-10-02 08:43:13 +08:00
|
|
|
long state; /* incremented whenever the indices move */
|
2004-05-30 15:26:47 +08:00
|
|
|
PyObject *weakreflist; /* List of weak references */
|
2004-01-29 14:37:52 +08:00
|
|
|
} dequeobject;
|
|
|
|
|
2004-02-29 23:40:53 +08:00
|
|
|
static PyTypeObject deque_type;
|
2004-02-29 10:15:56 +08:00
|
|
|
|
2004-01-29 14:37:52 +08:00
|
|
|
static PyObject *
|
|
|
|
deque_new(PyTypeObject *type, PyObject *args, PyObject *kwds)
|
|
|
|
{
|
|
|
|
dequeobject *deque;
|
|
|
|
block *b;
|
|
|
|
|
|
|
|
/* create dequeobject structure */
|
|
|
|
deque = (dequeobject *)type->tp_alloc(type, 0);
|
|
|
|
if (deque == NULL)
|
|
|
|
return NULL;
|
2004-10-01 09:03:29 +08:00
|
|
|
|
2004-10-07 01:51:54 +08:00
|
|
|
b = newblock(NULL, NULL, 0);
|
2004-01-29 14:37:52 +08:00
|
|
|
if (b == NULL) {
|
|
|
|
Py_DECREF(deque);
|
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
|
2004-10-01 14:24:12 +08:00
|
|
|
assert(BLOCKLEN >= 2);
|
2004-01-29 14:37:52 +08:00
|
|
|
deque->leftblock = b;
|
|
|
|
deque->rightblock = b;
|
2004-10-01 14:24:12 +08:00
|
|
|
deque->leftindex = CENTER + 1;
|
|
|
|
deque->rightindex = CENTER;
|
2004-01-29 14:37:52 +08:00
|
|
|
deque->len = 0;
|
2004-10-02 08:43:13 +08:00
|
|
|
deque->state = 0;
|
2004-05-30 15:26:47 +08:00
|
|
|
deque->weakreflist = NULL;
|
2004-01-29 14:37:52 +08:00
|
|
|
|
|
|
|
return (PyObject *)deque;
|
|
|
|
}
|
|
|
|
|
|
|
|
static PyObject *
|
|
|
|
deque_append(dequeobject *deque, PyObject *item)
|
|
|
|
{
|
2004-10-02 08:43:13 +08:00
|
|
|
deque->state++;
|
Upon insertion, if memory runs out, the deque was left in a corrupted state.
deque_item(): a performance bug: the linked list of blocks was followed
from the left in most cases, because the test (i < (deque->len >> 1)) was
after "i %= BLOCKLEN".
deque_clear(): replaced a call to deque_len() with deque->len; not sure what
this call was here for, nor if all compilers under the sun would inline it.
deque_traverse(): I belive that it could be called by the GC when the deque
has leftblock==rightblock==NULL, because it is tracked before the first block
is allocated (though closely before). Still, a C extension module subclassing
deque could provide its own tp_alloc that could trigger a GC collection after
the PyObject_GC_Track()...
deque_richcompare(): rewrote to cleanly check for end-of-iterations instead of
relying on deque.__iter__().next() to succeed exactly len(deque) times -- an
assumption which can break if deques are subclassed. Added a test.
I wonder if the length should be explicitely bounded to INT_MAX, with
OverflowErrors, as in listobject.c. On 64-bit machines, adding more than
INT_MAX in the deque will result in trouble. (Note to anyone/me fixing
this: carefully check for overflows if len is close to INT_MAX in the
following functions: deque_rotate(), deque_item(), deque_ass_item())
2004-10-02 21:59:34 +08:00
|
|
|
if (deque->rightindex == BLOCKLEN-1) {
|
2004-10-07 01:51:54 +08:00
|
|
|
block *b = newblock(deque->rightblock, NULL, deque->len);
|
2004-01-29 14:37:52 +08:00
|
|
|
if (b == NULL)
|
|
|
|
return NULL;
|
|
|
|
assert(deque->rightblock->rightlink == NULL);
|
|
|
|
deque->rightblock->rightlink = b;
|
|
|
|
deque->rightblock = b;
|
Upon insertion, if memory runs out, the deque was left in a corrupted state.
deque_item(): a performance bug: the linked list of blocks was followed
from the left in most cases, because the test (i < (deque->len >> 1)) was
after "i %= BLOCKLEN".
deque_clear(): replaced a call to deque_len() with deque->len; not sure what
this call was here for, nor if all compilers under the sun would inline it.
deque_traverse(): I belive that it could be called by the GC when the deque
has leftblock==rightblock==NULL, because it is tracked before the first block
is allocated (though closely before). Still, a C extension module subclassing
deque could provide its own tp_alloc that could trigger a GC collection after
the PyObject_GC_Track()...
deque_richcompare(): rewrote to cleanly check for end-of-iterations instead of
relying on deque.__iter__().next() to succeed exactly len(deque) times -- an
assumption which can break if deques are subclassed. Added a test.
I wonder if the length should be explicitely bounded to INT_MAX, with
OverflowErrors, as in listobject.c. On 64-bit machines, adding more than
INT_MAX in the deque will result in trouble. (Note to anyone/me fixing
this: carefully check for overflows if len is close to INT_MAX in the
following functions: deque_rotate(), deque_item(), deque_ass_item())
2004-10-02 21:59:34 +08:00
|
|
|
deque->rightindex = -1;
|
2004-01-29 14:37:52 +08:00
|
|
|
}
|
|
|
|
Py_INCREF(item);
|
Upon insertion, if memory runs out, the deque was left in a corrupted state.
deque_item(): a performance bug: the linked list of blocks was followed
from the left in most cases, because the test (i < (deque->len >> 1)) was
after "i %= BLOCKLEN".
deque_clear(): replaced a call to deque_len() with deque->len; not sure what
this call was here for, nor if all compilers under the sun would inline it.
deque_traverse(): I belive that it could be called by the GC when the deque
has leftblock==rightblock==NULL, because it is tracked before the first block
is allocated (though closely before). Still, a C extension module subclassing
deque could provide its own tp_alloc that could trigger a GC collection after
the PyObject_GC_Track()...
deque_richcompare(): rewrote to cleanly check for end-of-iterations instead of
relying on deque.__iter__().next() to succeed exactly len(deque) times -- an
assumption which can break if deques are subclassed. Added a test.
I wonder if the length should be explicitely bounded to INT_MAX, with
OverflowErrors, as in listobject.c. On 64-bit machines, adding more than
INT_MAX in the deque will result in trouble. (Note to anyone/me fixing
this: carefully check for overflows if len is close to INT_MAX in the
following functions: deque_rotate(), deque_item(), deque_ass_item())
2004-10-02 21:59:34 +08:00
|
|
|
deque->len++;
|
|
|
|
deque->rightindex++;
|
2004-01-29 14:37:52 +08:00
|
|
|
deque->rightblock->data[deque->rightindex] = item;
|
|
|
|
Py_RETURN_NONE;
|
|
|
|
}
|
|
|
|
|
|
|
|
PyDoc_STRVAR(append_doc, "Add an element to the right side of the deque.");
|
|
|
|
|
|
|
|
static PyObject *
|
|
|
|
deque_appendleft(dequeobject *deque, PyObject *item)
|
|
|
|
{
|
2004-10-02 08:43:13 +08:00
|
|
|
deque->state++;
|
Upon insertion, if memory runs out, the deque was left in a corrupted state.
deque_item(): a performance bug: the linked list of blocks was followed
from the left in most cases, because the test (i < (deque->len >> 1)) was
after "i %= BLOCKLEN".
deque_clear(): replaced a call to deque_len() with deque->len; not sure what
this call was here for, nor if all compilers under the sun would inline it.
deque_traverse(): I belive that it could be called by the GC when the deque
has leftblock==rightblock==NULL, because it is tracked before the first block
is allocated (though closely before). Still, a C extension module subclassing
deque could provide its own tp_alloc that could trigger a GC collection after
the PyObject_GC_Track()...
deque_richcompare(): rewrote to cleanly check for end-of-iterations instead of
relying on deque.__iter__().next() to succeed exactly len(deque) times -- an
assumption which can break if deques are subclassed. Added a test.
I wonder if the length should be explicitely bounded to INT_MAX, with
OverflowErrors, as in listobject.c. On 64-bit machines, adding more than
INT_MAX in the deque will result in trouble. (Note to anyone/me fixing
this: carefully check for overflows if len is close to INT_MAX in the
following functions: deque_rotate(), deque_item(), deque_ass_item())
2004-10-02 21:59:34 +08:00
|
|
|
if (deque->leftindex == 0) {
|
2004-10-07 01:51:54 +08:00
|
|
|
block *b = newblock(NULL, deque->leftblock, deque->len);
|
2004-01-29 14:37:52 +08:00
|
|
|
if (b == NULL)
|
|
|
|
return NULL;
|
|
|
|
assert(deque->leftblock->leftlink == NULL);
|
|
|
|
deque->leftblock->leftlink = b;
|
|
|
|
deque->leftblock = b;
|
Upon insertion, if memory runs out, the deque was left in a corrupted state.
deque_item(): a performance bug: the linked list of blocks was followed
from the left in most cases, because the test (i < (deque->len >> 1)) was
after "i %= BLOCKLEN".
deque_clear(): replaced a call to deque_len() with deque->len; not sure what
this call was here for, nor if all compilers under the sun would inline it.
deque_traverse(): I belive that it could be called by the GC when the deque
has leftblock==rightblock==NULL, because it is tracked before the first block
is allocated (though closely before). Still, a C extension module subclassing
deque could provide its own tp_alloc that could trigger a GC collection after
the PyObject_GC_Track()...
deque_richcompare(): rewrote to cleanly check for end-of-iterations instead of
relying on deque.__iter__().next() to succeed exactly len(deque) times -- an
assumption which can break if deques are subclassed. Added a test.
I wonder if the length should be explicitely bounded to INT_MAX, with
OverflowErrors, as in listobject.c. On 64-bit machines, adding more than
INT_MAX in the deque will result in trouble. (Note to anyone/me fixing
this: carefully check for overflows if len is close to INT_MAX in the
following functions: deque_rotate(), deque_item(), deque_ass_item())
2004-10-02 21:59:34 +08:00
|
|
|
deque->leftindex = BLOCKLEN;
|
2004-01-29 14:37:52 +08:00
|
|
|
}
|
|
|
|
Py_INCREF(item);
|
Upon insertion, if memory runs out, the deque was left in a corrupted state.
deque_item(): a performance bug: the linked list of blocks was followed
from the left in most cases, because the test (i < (deque->len >> 1)) was
after "i %= BLOCKLEN".
deque_clear(): replaced a call to deque_len() with deque->len; not sure what
this call was here for, nor if all compilers under the sun would inline it.
deque_traverse(): I belive that it could be called by the GC when the deque
has leftblock==rightblock==NULL, because it is tracked before the first block
is allocated (though closely before). Still, a C extension module subclassing
deque could provide its own tp_alloc that could trigger a GC collection after
the PyObject_GC_Track()...
deque_richcompare(): rewrote to cleanly check for end-of-iterations instead of
relying on deque.__iter__().next() to succeed exactly len(deque) times -- an
assumption which can break if deques are subclassed. Added a test.
I wonder if the length should be explicitely bounded to INT_MAX, with
OverflowErrors, as in listobject.c. On 64-bit machines, adding more than
INT_MAX in the deque will result in trouble. (Note to anyone/me fixing
this: carefully check for overflows if len is close to INT_MAX in the
following functions: deque_rotate(), deque_item(), deque_ass_item())
2004-10-02 21:59:34 +08:00
|
|
|
deque->len++;
|
|
|
|
deque->leftindex--;
|
2004-01-29 14:37:52 +08:00
|
|
|
deque->leftblock->data[deque->leftindex] = item;
|
|
|
|
Py_RETURN_NONE;
|
|
|
|
}
|
|
|
|
|
|
|
|
PyDoc_STRVAR(appendleft_doc, "Add an element to the left side of the deque.");
|
|
|
|
|
|
|
|
static PyObject *
|
|
|
|
deque_pop(dequeobject *deque, PyObject *unused)
|
|
|
|
{
|
|
|
|
PyObject *item;
|
|
|
|
block *prevblock;
|
|
|
|
|
|
|
|
if (deque->len == 0) {
|
2004-02-29 10:15:56 +08:00
|
|
|
PyErr_SetString(PyExc_IndexError, "pop from an empty deque");
|
2004-01-29 14:37:52 +08:00
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
item = deque->rightblock->data[deque->rightindex];
|
|
|
|
deque->rightindex--;
|
|
|
|
deque->len--;
|
2004-10-02 08:43:13 +08:00
|
|
|
deque->state++;
|
2004-01-29 14:37:52 +08:00
|
|
|
|
|
|
|
if (deque->rightindex == -1) {
|
|
|
|
if (deque->len == 0) {
|
|
|
|
assert(deque->leftblock == deque->rightblock);
|
|
|
|
assert(deque->leftindex == deque->rightindex+1);
|
|
|
|
/* re-center instead of freeing a block */
|
2004-10-01 14:24:12 +08:00
|
|
|
deque->leftindex = CENTER + 1;
|
|
|
|
deque->rightindex = CENTER;
|
2004-01-29 14:37:52 +08:00
|
|
|
} else {
|
|
|
|
prevblock = deque->rightblock->leftlink;
|
|
|
|
assert(deque->leftblock != deque->rightblock);
|
|
|
|
PyMem_Free(deque->rightblock);
|
|
|
|
prevblock->rightlink = NULL;
|
|
|
|
deque->rightblock = prevblock;
|
|
|
|
deque->rightindex = BLOCKLEN - 1;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
return item;
|
|
|
|
}
|
|
|
|
|
|
|
|
PyDoc_STRVAR(pop_doc, "Remove and return the rightmost element.");
|
|
|
|
|
|
|
|
static PyObject *
|
|
|
|
deque_popleft(dequeobject *deque, PyObject *unused)
|
|
|
|
{
|
|
|
|
PyObject *item;
|
|
|
|
block *prevblock;
|
|
|
|
|
|
|
|
if (deque->len == 0) {
|
2004-02-29 10:15:56 +08:00
|
|
|
PyErr_SetString(PyExc_IndexError, "pop from an empty deque");
|
2004-01-29 14:37:52 +08:00
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
item = deque->leftblock->data[deque->leftindex];
|
|
|
|
deque->leftindex++;
|
|
|
|
deque->len--;
|
2004-10-02 08:43:13 +08:00
|
|
|
deque->state++;
|
2004-01-29 14:37:52 +08:00
|
|
|
|
|
|
|
if (deque->leftindex == BLOCKLEN) {
|
|
|
|
if (deque->len == 0) {
|
|
|
|
assert(deque->leftblock == deque->rightblock);
|
|
|
|
assert(deque->leftindex == deque->rightindex+1);
|
|
|
|
/* re-center instead of freeing a block */
|
2004-10-01 14:24:12 +08:00
|
|
|
deque->leftindex = CENTER + 1;
|
|
|
|
deque->rightindex = CENTER;
|
2004-01-29 14:37:52 +08:00
|
|
|
} else {
|
|
|
|
assert(deque->leftblock != deque->rightblock);
|
|
|
|
prevblock = deque->leftblock->rightlink;
|
|
|
|
assert(deque->leftblock != NULL);
|
|
|
|
PyMem_Free(deque->leftblock);
|
|
|
|
assert(prevblock != NULL);
|
|
|
|
prevblock->leftlink = NULL;
|
|
|
|
deque->leftblock = prevblock;
|
|
|
|
deque->leftindex = 0;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
return item;
|
|
|
|
}
|
|
|
|
|
|
|
|
PyDoc_STRVAR(popleft_doc, "Remove and return the leftmost element.");
|
|
|
|
|
2004-02-07 03:04:56 +08:00
|
|
|
static PyObject *
|
|
|
|
deque_extend(dequeobject *deque, PyObject *iterable)
|
|
|
|
{
|
|
|
|
PyObject *it, *item;
|
|
|
|
|
|
|
|
it = PyObject_GetIter(iterable);
|
|
|
|
if (it == NULL)
|
|
|
|
return NULL;
|
|
|
|
|
|
|
|
while ((item = PyIter_Next(it)) != NULL) {
|
2004-10-02 08:43:13 +08:00
|
|
|
deque->state++;
|
Upon insertion, if memory runs out, the deque was left in a corrupted state.
deque_item(): a performance bug: the linked list of blocks was followed
from the left in most cases, because the test (i < (deque->len >> 1)) was
after "i %= BLOCKLEN".
deque_clear(): replaced a call to deque_len() with deque->len; not sure what
this call was here for, nor if all compilers under the sun would inline it.
deque_traverse(): I belive that it could be called by the GC when the deque
has leftblock==rightblock==NULL, because it is tracked before the first block
is allocated (though closely before). Still, a C extension module subclassing
deque could provide its own tp_alloc that could trigger a GC collection after
the PyObject_GC_Track()...
deque_richcompare(): rewrote to cleanly check for end-of-iterations instead of
relying on deque.__iter__().next() to succeed exactly len(deque) times -- an
assumption which can break if deques are subclassed. Added a test.
I wonder if the length should be explicitely bounded to INT_MAX, with
OverflowErrors, as in listobject.c. On 64-bit machines, adding more than
INT_MAX in the deque will result in trouble. (Note to anyone/me fixing
this: carefully check for overflows if len is close to INT_MAX in the
following functions: deque_rotate(), deque_item(), deque_ass_item())
2004-10-02 21:59:34 +08:00
|
|
|
if (deque->rightindex == BLOCKLEN-1) {
|
2004-10-07 01:51:54 +08:00
|
|
|
block *b = newblock(deque->rightblock, NULL,
|
|
|
|
deque->len);
|
2004-02-07 10:45:22 +08:00
|
|
|
if (b == NULL) {
|
|
|
|
Py_DECREF(item);
|
|
|
|
Py_DECREF(it);
|
2004-02-07 03:04:56 +08:00
|
|
|
return NULL;
|
2004-02-07 10:45:22 +08:00
|
|
|
}
|
2004-02-07 03:04:56 +08:00
|
|
|
assert(deque->rightblock->rightlink == NULL);
|
|
|
|
deque->rightblock->rightlink = b;
|
|
|
|
deque->rightblock = b;
|
Upon insertion, if memory runs out, the deque was left in a corrupted state.
deque_item(): a performance bug: the linked list of blocks was followed
from the left in most cases, because the test (i < (deque->len >> 1)) was
after "i %= BLOCKLEN".
deque_clear(): replaced a call to deque_len() with deque->len; not sure what
this call was here for, nor if all compilers under the sun would inline it.
deque_traverse(): I belive that it could be called by the GC when the deque
has leftblock==rightblock==NULL, because it is tracked before the first block
is allocated (though closely before). Still, a C extension module subclassing
deque could provide its own tp_alloc that could trigger a GC collection after
the PyObject_GC_Track()...
deque_richcompare(): rewrote to cleanly check for end-of-iterations instead of
relying on deque.__iter__().next() to succeed exactly len(deque) times -- an
assumption which can break if deques are subclassed. Added a test.
I wonder if the length should be explicitely bounded to INT_MAX, with
OverflowErrors, as in listobject.c. On 64-bit machines, adding more than
INT_MAX in the deque will result in trouble. (Note to anyone/me fixing
this: carefully check for overflows if len is close to INT_MAX in the
following functions: deque_rotate(), deque_item(), deque_ass_item())
2004-10-02 21:59:34 +08:00
|
|
|
deque->rightindex = -1;
|
2004-02-07 03:04:56 +08:00
|
|
|
}
|
Upon insertion, if memory runs out, the deque was left in a corrupted state.
deque_item(): a performance bug: the linked list of blocks was followed
from the left in most cases, because the test (i < (deque->len >> 1)) was
after "i %= BLOCKLEN".
deque_clear(): replaced a call to deque_len() with deque->len; not sure what
this call was here for, nor if all compilers under the sun would inline it.
deque_traverse(): I belive that it could be called by the GC when the deque
has leftblock==rightblock==NULL, because it is tracked before the first block
is allocated (though closely before). Still, a C extension module subclassing
deque could provide its own tp_alloc that could trigger a GC collection after
the PyObject_GC_Track()...
deque_richcompare(): rewrote to cleanly check for end-of-iterations instead of
relying on deque.__iter__().next() to succeed exactly len(deque) times -- an
assumption which can break if deques are subclassed. Added a test.
I wonder if the length should be explicitely bounded to INT_MAX, with
OverflowErrors, as in listobject.c. On 64-bit machines, adding more than
INT_MAX in the deque will result in trouble. (Note to anyone/me fixing
this: carefully check for overflows if len is close to INT_MAX in the
following functions: deque_rotate(), deque_item(), deque_ass_item())
2004-10-02 21:59:34 +08:00
|
|
|
deque->len++;
|
|
|
|
deque->rightindex++;
|
2004-02-07 03:04:56 +08:00
|
|
|
deque->rightblock->data[deque->rightindex] = item;
|
|
|
|
}
|
|
|
|
Py_DECREF(it);
|
2004-10-01 09:03:29 +08:00
|
|
|
if (PyErr_Occurred())
|
2004-02-07 03:04:56 +08:00
|
|
|
return NULL;
|
|
|
|
Py_RETURN_NONE;
|
|
|
|
}
|
|
|
|
|
2004-10-01 09:03:29 +08:00
|
|
|
PyDoc_STRVAR(extend_doc,
|
2004-02-07 03:04:56 +08:00
|
|
|
"Extend the right side of the deque with elements from the iterable");
|
|
|
|
|
|
|
|
static PyObject *
|
|
|
|
deque_extendleft(dequeobject *deque, PyObject *iterable)
|
|
|
|
{
|
|
|
|
PyObject *it, *item;
|
|
|
|
|
|
|
|
it = PyObject_GetIter(iterable);
|
|
|
|
if (it == NULL)
|
|
|
|
return NULL;
|
|
|
|
|
|
|
|
while ((item = PyIter_Next(it)) != NULL) {
|
2004-10-02 08:43:13 +08:00
|
|
|
deque->state++;
|
Upon insertion, if memory runs out, the deque was left in a corrupted state.
deque_item(): a performance bug: the linked list of blocks was followed
from the left in most cases, because the test (i < (deque->len >> 1)) was
after "i %= BLOCKLEN".
deque_clear(): replaced a call to deque_len() with deque->len; not sure what
this call was here for, nor if all compilers under the sun would inline it.
deque_traverse(): I belive that it could be called by the GC when the deque
has leftblock==rightblock==NULL, because it is tracked before the first block
is allocated (though closely before). Still, a C extension module subclassing
deque could provide its own tp_alloc that could trigger a GC collection after
the PyObject_GC_Track()...
deque_richcompare(): rewrote to cleanly check for end-of-iterations instead of
relying on deque.__iter__().next() to succeed exactly len(deque) times -- an
assumption which can break if deques are subclassed. Added a test.
I wonder if the length should be explicitely bounded to INT_MAX, with
OverflowErrors, as in listobject.c. On 64-bit machines, adding more than
INT_MAX in the deque will result in trouble. (Note to anyone/me fixing
this: carefully check for overflows if len is close to INT_MAX in the
following functions: deque_rotate(), deque_item(), deque_ass_item())
2004-10-02 21:59:34 +08:00
|
|
|
if (deque->leftindex == 0) {
|
2004-10-07 01:51:54 +08:00
|
|
|
block *b = newblock(NULL, deque->leftblock,
|
|
|
|
deque->len);
|
2004-02-07 10:45:22 +08:00
|
|
|
if (b == NULL) {
|
|
|
|
Py_DECREF(item);
|
|
|
|
Py_DECREF(it);
|
2004-02-07 03:04:56 +08:00
|
|
|
return NULL;
|
2004-02-07 10:45:22 +08:00
|
|
|
}
|
2004-02-07 03:04:56 +08:00
|
|
|
assert(deque->leftblock->leftlink == NULL);
|
|
|
|
deque->leftblock->leftlink = b;
|
|
|
|
deque->leftblock = b;
|
Upon insertion, if memory runs out, the deque was left in a corrupted state.
deque_item(): a performance bug: the linked list of blocks was followed
from the left in most cases, because the test (i < (deque->len >> 1)) was
after "i %= BLOCKLEN".
deque_clear(): replaced a call to deque_len() with deque->len; not sure what
this call was here for, nor if all compilers under the sun would inline it.
deque_traverse(): I belive that it could be called by the GC when the deque
has leftblock==rightblock==NULL, because it is tracked before the first block
is allocated (though closely before). Still, a C extension module subclassing
deque could provide its own tp_alloc that could trigger a GC collection after
the PyObject_GC_Track()...
deque_richcompare(): rewrote to cleanly check for end-of-iterations instead of
relying on deque.__iter__().next() to succeed exactly len(deque) times -- an
assumption which can break if deques are subclassed. Added a test.
I wonder if the length should be explicitely bounded to INT_MAX, with
OverflowErrors, as in listobject.c. On 64-bit machines, adding more than
INT_MAX in the deque will result in trouble. (Note to anyone/me fixing
this: carefully check for overflows if len is close to INT_MAX in the
following functions: deque_rotate(), deque_item(), deque_ass_item())
2004-10-02 21:59:34 +08:00
|
|
|
deque->leftindex = BLOCKLEN;
|
2004-02-07 03:04:56 +08:00
|
|
|
}
|
Upon insertion, if memory runs out, the deque was left in a corrupted state.
deque_item(): a performance bug: the linked list of blocks was followed
from the left in most cases, because the test (i < (deque->len >> 1)) was
after "i %= BLOCKLEN".
deque_clear(): replaced a call to deque_len() with deque->len; not sure what
this call was here for, nor if all compilers under the sun would inline it.
deque_traverse(): I belive that it could be called by the GC when the deque
has leftblock==rightblock==NULL, because it is tracked before the first block
is allocated (though closely before). Still, a C extension module subclassing
deque could provide its own tp_alloc that could trigger a GC collection after
the PyObject_GC_Track()...
deque_richcompare(): rewrote to cleanly check for end-of-iterations instead of
relying on deque.__iter__().next() to succeed exactly len(deque) times -- an
assumption which can break if deques are subclassed. Added a test.
I wonder if the length should be explicitely bounded to INT_MAX, with
OverflowErrors, as in listobject.c. On 64-bit machines, adding more than
INT_MAX in the deque will result in trouble. (Note to anyone/me fixing
this: carefully check for overflows if len is close to INT_MAX in the
following functions: deque_rotate(), deque_item(), deque_ass_item())
2004-10-02 21:59:34 +08:00
|
|
|
deque->len++;
|
|
|
|
deque->leftindex--;
|
2004-02-07 03:04:56 +08:00
|
|
|
deque->leftblock->data[deque->leftindex] = item;
|
|
|
|
}
|
|
|
|
Py_DECREF(it);
|
2004-07-09 12:10:20 +08:00
|
|
|
if (PyErr_Occurred())
|
2004-02-07 03:04:56 +08:00
|
|
|
return NULL;
|
|
|
|
Py_RETURN_NONE;
|
|
|
|
}
|
|
|
|
|
2004-10-01 09:03:29 +08:00
|
|
|
PyDoc_STRVAR(extendleft_doc,
|
2004-02-07 03:04:56 +08:00
|
|
|
"Extend the left side of the deque with elements from the iterable");
|
|
|
|
|
2004-10-10 00:02:18 +08:00
|
|
|
static int
|
|
|
|
_deque_rotate(dequeobject *deque, int n)
|
2004-02-08 05:13:00 +08:00
|
|
|
{
|
2004-10-10 00:02:18 +08:00
|
|
|
int i, len=deque->len, halflen=(len+1)>>1;
|
2004-02-08 05:13:00 +08:00
|
|
|
PyObject *item, *rv;
|
|
|
|
|
2004-02-08 12:05:26 +08:00
|
|
|
if (len == 0)
|
2004-10-10 00:02:18 +08:00
|
|
|
return 0;
|
2004-02-08 12:05:26 +08:00
|
|
|
if (n > halflen || n < -halflen) {
|
|
|
|
n %= len;
|
|
|
|
if (n > halflen)
|
|
|
|
n -= len;
|
|
|
|
else if (n < -halflen)
|
|
|
|
n += len;
|
|
|
|
}
|
2004-02-08 05:13:00 +08:00
|
|
|
|
|
|
|
for (i=0 ; i<n ; i++) {
|
|
|
|
item = deque_pop(deque, NULL);
|
2004-07-09 12:10:20 +08:00
|
|
|
assert (item != NULL);
|
2004-02-08 05:13:00 +08:00
|
|
|
rv = deque_appendleft(deque, item);
|
|
|
|
Py_DECREF(item);
|
|
|
|
if (rv == NULL)
|
2004-10-10 00:02:18 +08:00
|
|
|
return -1;
|
2004-02-08 05:13:00 +08:00
|
|
|
Py_DECREF(rv);
|
|
|
|
}
|
|
|
|
for (i=0 ; i>n ; i--) {
|
|
|
|
item = deque_popleft(deque, NULL);
|
2004-07-09 12:10:20 +08:00
|
|
|
assert (item != NULL);
|
2004-02-08 05:13:00 +08:00
|
|
|
rv = deque_append(deque, item);
|
|
|
|
Py_DECREF(item);
|
|
|
|
if (rv == NULL)
|
2004-10-10 00:02:18 +08:00
|
|
|
return -1;
|
2004-02-08 05:13:00 +08:00
|
|
|
Py_DECREF(rv);
|
|
|
|
}
|
2004-10-10 00:02:18 +08:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
static PyObject *
|
|
|
|
deque_rotate(dequeobject *deque, PyObject *args)
|
|
|
|
{
|
|
|
|
int n=1;
|
|
|
|
|
|
|
|
if (!PyArg_ParseTuple(args, "|i:rotate", &n))
|
|
|
|
return NULL;
|
|
|
|
if (_deque_rotate(deque, n) == 0)
|
|
|
|
Py_RETURN_NONE;
|
|
|
|
return NULL;
|
2004-02-08 05:13:00 +08:00
|
|
|
}
|
|
|
|
|
2004-10-01 09:03:29 +08:00
|
|
|
PyDoc_STRVAR(rotate_doc,
|
2004-02-08 12:05:26 +08:00
|
|
|
"Rotate the deque n steps to the right (default n=1). If n is negative, rotates left.");
|
2004-02-08 05:13:00 +08:00
|
|
|
|
2004-01-29 14:37:52 +08:00
|
|
|
static int
|
|
|
|
deque_len(dequeobject *deque)
|
|
|
|
{
|
|
|
|
return deque->len;
|
|
|
|
}
|
|
|
|
|
|
|
|
static int
|
|
|
|
deque_clear(dequeobject *deque)
|
|
|
|
{
|
|
|
|
PyObject *item;
|
|
|
|
|
2004-10-02 08:43:13 +08:00
|
|
|
while (deque->len) {
|
2004-01-29 14:37:52 +08:00
|
|
|
item = deque_pop(deque, NULL);
|
2004-07-09 12:10:20 +08:00
|
|
|
assert (item != NULL);
|
2004-01-29 14:37:52 +08:00
|
|
|
Py_DECREF(item);
|
|
|
|
}
|
|
|
|
assert(deque->leftblock == deque->rightblock &&
|
2004-10-02 08:43:13 +08:00
|
|
|
deque->leftindex - 1 == deque->rightindex &&
|
|
|
|
deque->len == 0);
|
2004-01-29 14:37:52 +08:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2004-03-02 07:16:22 +08:00
|
|
|
static PyObject *
|
|
|
|
deque_item(dequeobject *deque, int i)
|
|
|
|
{
|
|
|
|
block *b;
|
|
|
|
PyObject *item;
|
Upon insertion, if memory runs out, the deque was left in a corrupted state.
deque_item(): a performance bug: the linked list of blocks was followed
from the left in most cases, because the test (i < (deque->len >> 1)) was
after "i %= BLOCKLEN".
deque_clear(): replaced a call to deque_len() with deque->len; not sure what
this call was here for, nor if all compilers under the sun would inline it.
deque_traverse(): I belive that it could be called by the GC when the deque
has leftblock==rightblock==NULL, because it is tracked before the first block
is allocated (though closely before). Still, a C extension module subclassing
deque could provide its own tp_alloc that could trigger a GC collection after
the PyObject_GC_Track()...
deque_richcompare(): rewrote to cleanly check for end-of-iterations instead of
relying on deque.__iter__().next() to succeed exactly len(deque) times -- an
assumption which can break if deques are subclassed. Added a test.
I wonder if the length should be explicitely bounded to INT_MAX, with
OverflowErrors, as in listobject.c. On 64-bit machines, adding more than
INT_MAX in the deque will result in trouble. (Note to anyone/me fixing
this: carefully check for overflows if len is close to INT_MAX in the
following functions: deque_rotate(), deque_item(), deque_ass_item())
2004-10-02 21:59:34 +08:00
|
|
|
int n, index=i;
|
2004-03-02 07:16:22 +08:00
|
|
|
|
|
|
|
if (i < 0 || i >= deque->len) {
|
|
|
|
PyErr_SetString(PyExc_IndexError,
|
|
|
|
"deque index out of range");
|
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
|
2004-03-04 16:00:54 +08:00
|
|
|
if (i == 0) {
|
|
|
|
i = deque->leftindex;
|
2004-03-02 07:16:22 +08:00
|
|
|
b = deque->leftblock;
|
2004-03-04 16:00:54 +08:00
|
|
|
} else if (i == deque->len - 1) {
|
|
|
|
i = deque->rightindex;
|
2004-03-02 07:16:22 +08:00
|
|
|
b = deque->rightblock;
|
2004-03-04 16:00:54 +08:00
|
|
|
} else {
|
|
|
|
i += deque->leftindex;
|
|
|
|
n = i / BLOCKLEN;
|
|
|
|
i %= BLOCKLEN;
|
Upon insertion, if memory runs out, the deque was left in a corrupted state.
deque_item(): a performance bug: the linked list of blocks was followed
from the left in most cases, because the test (i < (deque->len >> 1)) was
after "i %= BLOCKLEN".
deque_clear(): replaced a call to deque_len() with deque->len; not sure what
this call was here for, nor if all compilers under the sun would inline it.
deque_traverse(): I belive that it could be called by the GC when the deque
has leftblock==rightblock==NULL, because it is tracked before the first block
is allocated (though closely before). Still, a C extension module subclassing
deque could provide its own tp_alloc that could trigger a GC collection after
the PyObject_GC_Track()...
deque_richcompare(): rewrote to cleanly check for end-of-iterations instead of
relying on deque.__iter__().next() to succeed exactly len(deque) times -- an
assumption which can break if deques are subclassed. Added a test.
I wonder if the length should be explicitely bounded to INT_MAX, with
OverflowErrors, as in listobject.c. On 64-bit machines, adding more than
INT_MAX in the deque will result in trouble. (Note to anyone/me fixing
this: carefully check for overflows if len is close to INT_MAX in the
following functions: deque_rotate(), deque_item(), deque_ass_item())
2004-10-02 21:59:34 +08:00
|
|
|
if (index < (deque->len >> 1)) {
|
2004-03-04 16:00:54 +08:00
|
|
|
b = deque->leftblock;
|
|
|
|
while (n--)
|
|
|
|
b = b->rightlink;
|
|
|
|
} else {
|
|
|
|
n = (deque->leftindex + deque->len - 1) / BLOCKLEN - n;
|
|
|
|
b = deque->rightblock;
|
|
|
|
while (n--)
|
|
|
|
b = b->leftlink;
|
|
|
|
}
|
2004-03-02 07:16:22 +08:00
|
|
|
}
|
|
|
|
item = b->data[i];
|
|
|
|
Py_INCREF(item);
|
|
|
|
return item;
|
|
|
|
}
|
|
|
|
|
2004-06-26 12:42:06 +08:00
|
|
|
/* delitem() implemented in terms of rotate for simplicity and reasonable
|
|
|
|
performance near the end points. If for some reason this method becomes
|
2004-10-01 09:03:29 +08:00
|
|
|
popular, it is not hard to re-implement this using direct data movement
|
2004-06-26 12:42:06 +08:00
|
|
|
(similar to code in list slice assignment) and achieve a two or threefold
|
|
|
|
performance boost.
|
|
|
|
*/
|
|
|
|
|
2004-05-13 04:55:56 +08:00
|
|
|
static int
|
|
|
|
deque_del_item(dequeobject *deque, int i)
|
|
|
|
{
|
2004-10-10 00:02:18 +08:00
|
|
|
PyObject *item;
|
2004-05-13 04:55:56 +08:00
|
|
|
|
2004-10-01 09:03:29 +08:00
|
|
|
assert (i >= 0 && i < deque->len);
|
2004-10-10 00:02:18 +08:00
|
|
|
if (_deque_rotate(deque, -i) == -1)
|
|
|
|
return -1;
|
2004-05-13 04:55:56 +08:00
|
|
|
|
|
|
|
item = deque_popleft(deque, NULL);
|
2004-07-09 12:10:20 +08:00
|
|
|
assert (item != NULL);
|
2004-05-13 04:55:56 +08:00
|
|
|
Py_DECREF(item);
|
|
|
|
|
2004-10-10 00:02:18 +08:00
|
|
|
return _deque_rotate(deque, i);
|
2004-05-13 04:55:56 +08:00
|
|
|
}
|
|
|
|
|
2004-03-02 07:16:22 +08:00
|
|
|
static int
|
|
|
|
deque_ass_item(dequeobject *deque, int i, PyObject *v)
|
|
|
|
{
|
|
|
|
PyObject *old_value;
|
|
|
|
block *b;
|
2004-07-09 12:10:20 +08:00
|
|
|
int n, len=deque->len, halflen=(len+1)>>1, index=i;
|
2004-03-02 07:16:22 +08:00
|
|
|
|
2004-07-09 12:10:20 +08:00
|
|
|
if (i < 0 || i >= len) {
|
2004-03-02 07:16:22 +08:00
|
|
|
PyErr_SetString(PyExc_IndexError,
|
|
|
|
"deque index out of range");
|
|
|
|
return -1;
|
|
|
|
}
|
2004-05-13 04:55:56 +08:00
|
|
|
if (v == NULL)
|
|
|
|
return deque_del_item(deque, i);
|
|
|
|
|
2004-03-02 07:16:22 +08:00
|
|
|
i += deque->leftindex;
|
|
|
|
n = i / BLOCKLEN;
|
|
|
|
i %= BLOCKLEN;
|
2004-07-09 12:10:20 +08:00
|
|
|
if (index <= halflen) {
|
2004-03-02 07:16:22 +08:00
|
|
|
b = deque->leftblock;
|
|
|
|
while (n--)
|
|
|
|
b = b->rightlink;
|
|
|
|
} else {
|
2004-07-09 12:10:20 +08:00
|
|
|
n = (deque->leftindex + len - 1) / BLOCKLEN - n;
|
2004-03-02 07:16:22 +08:00
|
|
|
b = deque->rightblock;
|
|
|
|
while (n--)
|
|
|
|
b = b->leftlink;
|
|
|
|
}
|
|
|
|
Py_INCREF(v);
|
|
|
|
old_value = b->data[i];
|
|
|
|
b->data[i] = v;
|
|
|
|
Py_DECREF(old_value);
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2004-01-29 14:37:52 +08:00
|
|
|
static PyObject *
|
|
|
|
deque_clearmethod(dequeobject *deque)
|
|
|
|
{
|
2004-07-09 12:10:20 +08:00
|
|
|
int rv;
|
|
|
|
|
|
|
|
rv = deque_clear(deque);
|
|
|
|
assert (rv != -1);
|
2004-01-29 14:37:52 +08:00
|
|
|
Py_RETURN_NONE;
|
|
|
|
}
|
|
|
|
|
|
|
|
PyDoc_STRVAR(clear_doc, "Remove all elements from the deque.");
|
|
|
|
|
|
|
|
static void
|
|
|
|
deque_dealloc(dequeobject *deque)
|
|
|
|
{
|
|
|
|
PyObject_GC_UnTrack(deque);
|
2004-05-30 15:26:47 +08:00
|
|
|
if (deque->weakreflist != NULL)
|
|
|
|
PyObject_ClearWeakRefs((PyObject *) deque);
|
2004-01-29 14:37:52 +08:00
|
|
|
if (deque->leftblock != NULL) {
|
2004-07-19 08:10:24 +08:00
|
|
|
deque_clear(deque);
|
2004-01-29 14:37:52 +08:00
|
|
|
assert(deque->leftblock != NULL);
|
|
|
|
PyMem_Free(deque->leftblock);
|
|
|
|
}
|
|
|
|
deque->leftblock = NULL;
|
|
|
|
deque->rightblock = NULL;
|
|
|
|
deque->ob_type->tp_free(deque);
|
|
|
|
}
|
|
|
|
|
|
|
|
static int
|
2004-03-02 07:16:22 +08:00
|
|
|
deque_traverse(dequeobject *deque, visitproc visit, void *arg)
|
2004-01-29 14:37:52 +08:00
|
|
|
{
|
2004-10-01 10:01:04 +08:00
|
|
|
block *b;
|
2004-01-29 14:37:52 +08:00
|
|
|
PyObject *item;
|
2004-10-01 10:01:04 +08:00
|
|
|
int index;
|
|
|
|
int indexlo = deque->leftindex;
|
|
|
|
|
|
|
|
for (b = deque->leftblock; b != NULL; b = b->rightlink) {
|
|
|
|
const int indexhi = b == deque->rightblock ?
|
|
|
|
deque->rightindex :
|
|
|
|
BLOCKLEN - 1;
|
|
|
|
|
|
|
|
for (index = indexlo; index <= indexhi; ++index) {
|
|
|
|
item = b->data[index];
|
|
|
|
Py_VISIT(item);
|
2004-01-29 14:37:52 +08:00
|
|
|
}
|
2004-10-01 10:01:04 +08:00
|
|
|
indexlo = 0;
|
2004-01-29 14:37:52 +08:00
|
|
|
}
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
static long
|
|
|
|
deque_nohash(PyObject *self)
|
|
|
|
{
|
|
|
|
PyErr_SetString(PyExc_TypeError, "deque objects are unhashable");
|
|
|
|
return -1;
|
|
|
|
}
|
|
|
|
|
|
|
|
static PyObject *
|
|
|
|
deque_copy(PyObject *deque)
|
|
|
|
{
|
2004-10-01 09:03:29 +08:00
|
|
|
return PyObject_CallFunctionObjArgs((PyObject *)(deque->ob_type),
|
2004-01-29 14:37:52 +08:00
|
|
|
deque, NULL);
|
|
|
|
}
|
|
|
|
|
|
|
|
PyDoc_STRVAR(copy_doc, "Return a shallow copy of a deque.");
|
|
|
|
|
|
|
|
static PyObject *
|
|
|
|
deque_reduce(dequeobject *deque)
|
|
|
|
{
|
|
|
|
PyObject *seq, *args, *result;
|
|
|
|
|
|
|
|
seq = PySequence_Tuple((PyObject *)deque);
|
|
|
|
if (seq == NULL)
|
|
|
|
return NULL;
|
|
|
|
args = PyTuple_Pack(1, seq);
|
|
|
|
if (args == NULL) {
|
|
|
|
Py_DECREF(seq);
|
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
result = PyTuple_Pack(2, deque->ob_type, args);
|
|
|
|
Py_DECREF(seq);
|
|
|
|
Py_DECREF(args);
|
|
|
|
return result;
|
|
|
|
}
|
|
|
|
|
|
|
|
PyDoc_STRVAR(reduce_doc, "Return state information for pickling.");
|
|
|
|
|
|
|
|
static PyObject *
|
|
|
|
deque_repr(PyObject *deque)
|
|
|
|
{
|
|
|
|
PyObject *aslist, *result, *fmt;
|
|
|
|
int i;
|
|
|
|
|
|
|
|
i = Py_ReprEnter(deque);
|
|
|
|
if (i != 0) {
|
|
|
|
if (i < 0)
|
|
|
|
return NULL;
|
|
|
|
return PyString_FromString("[...]");
|
|
|
|
}
|
|
|
|
|
|
|
|
aslist = PySequence_List(deque);
|
|
|
|
if (aslist == NULL) {
|
|
|
|
Py_ReprLeave(deque);
|
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
|
|
|
|
fmt = PyString_FromString("deque(%r)");
|
|
|
|
if (fmt == NULL) {
|
|
|
|
Py_DECREF(aslist);
|
|
|
|
Py_ReprLeave(deque);
|
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
result = PyString_Format(fmt, aslist);
|
|
|
|
Py_DECREF(fmt);
|
|
|
|
Py_DECREF(aslist);
|
|
|
|
Py_ReprLeave(deque);
|
|
|
|
return result;
|
|
|
|
}
|
|
|
|
|
|
|
|
static int
|
|
|
|
deque_tp_print(PyObject *deque, FILE *fp, int flags)
|
|
|
|
{
|
|
|
|
PyObject *it, *item;
|
|
|
|
char *emit = ""; /* No separator emitted on first pass */
|
|
|
|
char *separator = ", ";
|
|
|
|
int i;
|
|
|
|
|
|
|
|
i = Py_ReprEnter(deque);
|
|
|
|
if (i != 0) {
|
|
|
|
if (i < 0)
|
|
|
|
return i;
|
|
|
|
fputs("[...]", fp);
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
it = PyObject_GetIter(deque);
|
|
|
|
if (it == NULL)
|
|
|
|
return -1;
|
|
|
|
|
|
|
|
fputs("deque([", fp);
|
|
|
|
while ((item = PyIter_Next(it)) != NULL) {
|
|
|
|
fputs(emit, fp);
|
|
|
|
emit = separator;
|
|
|
|
if (PyObject_Print(item, fp, 0) != 0) {
|
|
|
|
Py_DECREF(item);
|
|
|
|
Py_DECREF(it);
|
|
|
|
Py_ReprLeave(deque);
|
|
|
|
return -1;
|
|
|
|
}
|
|
|
|
Py_DECREF(item);
|
|
|
|
}
|
|
|
|
Py_ReprLeave(deque);
|
|
|
|
Py_DECREF(it);
|
2004-10-01 09:03:29 +08:00
|
|
|
if (PyErr_Occurred())
|
2004-01-29 14:37:52 +08:00
|
|
|
return -1;
|
|
|
|
fputs("])", fp);
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2004-02-29 10:15:56 +08:00
|
|
|
static PyObject *
|
|
|
|
deque_richcompare(PyObject *v, PyObject *w, int op)
|
|
|
|
{
|
|
|
|
PyObject *it1=NULL, *it2=NULL, *x, *y;
|
Upon insertion, if memory runs out, the deque was left in a corrupted state.
deque_item(): a performance bug: the linked list of blocks was followed
from the left in most cases, because the test (i < (deque->len >> 1)) was
after "i %= BLOCKLEN".
deque_clear(): replaced a call to deque_len() with deque->len; not sure what
this call was here for, nor if all compilers under the sun would inline it.
deque_traverse(): I belive that it could be called by the GC when the deque
has leftblock==rightblock==NULL, because it is tracked before the first block
is allocated (though closely before). Still, a C extension module subclassing
deque could provide its own tp_alloc that could trigger a GC collection after
the PyObject_GC_Track()...
deque_richcompare(): rewrote to cleanly check for end-of-iterations instead of
relying on deque.__iter__().next() to succeed exactly len(deque) times -- an
assumption which can break if deques are subclassed. Added a test.
I wonder if the length should be explicitely bounded to INT_MAX, with
OverflowErrors, as in listobject.c. On 64-bit machines, adding more than
INT_MAX in the deque will result in trouble. (Note to anyone/me fixing
this: carefully check for overflows if len is close to INT_MAX in the
following functions: deque_rotate(), deque_item(), deque_ass_item())
2004-10-02 21:59:34 +08:00
|
|
|
int b, vs, ws, cmp=-1;
|
2004-02-29 10:15:56 +08:00
|
|
|
|
2004-10-01 09:03:29 +08:00
|
|
|
if (!PyObject_TypeCheck(v, &deque_type) ||
|
2004-05-19 02:15:03 +08:00
|
|
|
!PyObject_TypeCheck(w, &deque_type)) {
|
2004-02-29 10:15:56 +08:00
|
|
|
Py_INCREF(Py_NotImplemented);
|
|
|
|
return Py_NotImplemented;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Shortcuts */
|
|
|
|
vs = ((dequeobject *)v)->len;
|
|
|
|
ws = ((dequeobject *)w)->len;
|
|
|
|
if (op == Py_EQ) {
|
|
|
|
if (v == w)
|
|
|
|
Py_RETURN_TRUE;
|
|
|
|
if (vs != ws)
|
|
|
|
Py_RETURN_FALSE;
|
|
|
|
}
|
|
|
|
if (op == Py_NE) {
|
|
|
|
if (v == w)
|
|
|
|
Py_RETURN_FALSE;
|
|
|
|
if (vs != ws)
|
|
|
|
Py_RETURN_TRUE;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Search for the first index where items are different */
|
|
|
|
it1 = PyObject_GetIter(v);
|
|
|
|
if (it1 == NULL)
|
|
|
|
goto done;
|
|
|
|
it2 = PyObject_GetIter(w);
|
|
|
|
if (it2 == NULL)
|
|
|
|
goto done;
|
Upon insertion, if memory runs out, the deque was left in a corrupted state.
deque_item(): a performance bug: the linked list of blocks was followed
from the left in most cases, because the test (i < (deque->len >> 1)) was
after "i %= BLOCKLEN".
deque_clear(): replaced a call to deque_len() with deque->len; not sure what
this call was here for, nor if all compilers under the sun would inline it.
deque_traverse(): I belive that it could be called by the GC when the deque
has leftblock==rightblock==NULL, because it is tracked before the first block
is allocated (though closely before). Still, a C extension module subclassing
deque could provide its own tp_alloc that could trigger a GC collection after
the PyObject_GC_Track()...
deque_richcompare(): rewrote to cleanly check for end-of-iterations instead of
relying on deque.__iter__().next() to succeed exactly len(deque) times -- an
assumption which can break if deques are subclassed. Added a test.
I wonder if the length should be explicitely bounded to INT_MAX, with
OverflowErrors, as in listobject.c. On 64-bit machines, adding more than
INT_MAX in the deque will result in trouble. (Note to anyone/me fixing
this: carefully check for overflows if len is close to INT_MAX in the
following functions: deque_rotate(), deque_item(), deque_ass_item())
2004-10-02 21:59:34 +08:00
|
|
|
for (;;) {
|
2004-02-29 10:15:56 +08:00
|
|
|
x = PyIter_Next(it1);
|
Upon insertion, if memory runs out, the deque was left in a corrupted state.
deque_item(): a performance bug: the linked list of blocks was followed
from the left in most cases, because the test (i < (deque->len >> 1)) was
after "i %= BLOCKLEN".
deque_clear(): replaced a call to deque_len() with deque->len; not sure what
this call was here for, nor if all compilers under the sun would inline it.
deque_traverse(): I belive that it could be called by the GC when the deque
has leftblock==rightblock==NULL, because it is tracked before the first block
is allocated (though closely before). Still, a C extension module subclassing
deque could provide its own tp_alloc that could trigger a GC collection after
the PyObject_GC_Track()...
deque_richcompare(): rewrote to cleanly check for end-of-iterations instead of
relying on deque.__iter__().next() to succeed exactly len(deque) times -- an
assumption which can break if deques are subclassed. Added a test.
I wonder if the length should be explicitely bounded to INT_MAX, with
OverflowErrors, as in listobject.c. On 64-bit machines, adding more than
INT_MAX in the deque will result in trouble. (Note to anyone/me fixing
this: carefully check for overflows if len is close to INT_MAX in the
following functions: deque_rotate(), deque_item(), deque_ass_item())
2004-10-02 21:59:34 +08:00
|
|
|
if (x == NULL && PyErr_Occurred())
|
2004-02-29 10:15:56 +08:00
|
|
|
goto done;
|
|
|
|
y = PyIter_Next(it2);
|
Upon insertion, if memory runs out, the deque was left in a corrupted state.
deque_item(): a performance bug: the linked list of blocks was followed
from the left in most cases, because the test (i < (deque->len >> 1)) was
after "i %= BLOCKLEN".
deque_clear(): replaced a call to deque_len() with deque->len; not sure what
this call was here for, nor if all compilers under the sun would inline it.
deque_traverse(): I belive that it could be called by the GC when the deque
has leftblock==rightblock==NULL, because it is tracked before the first block
is allocated (though closely before). Still, a C extension module subclassing
deque could provide its own tp_alloc that could trigger a GC collection after
the PyObject_GC_Track()...
deque_richcompare(): rewrote to cleanly check for end-of-iterations instead of
relying on deque.__iter__().next() to succeed exactly len(deque) times -- an
assumption which can break if deques are subclassed. Added a test.
I wonder if the length should be explicitely bounded to INT_MAX, with
OverflowErrors, as in listobject.c. On 64-bit machines, adding more than
INT_MAX in the deque will result in trouble. (Note to anyone/me fixing
this: carefully check for overflows if len is close to INT_MAX in the
following functions: deque_rotate(), deque_item(), deque_ass_item())
2004-10-02 21:59:34 +08:00
|
|
|
if (x == NULL || y == NULL)
|
|
|
|
break;
|
2004-02-29 10:15:56 +08:00
|
|
|
b = PyObject_RichCompareBool(x, y, Py_EQ);
|
|
|
|
if (b == 0) {
|
|
|
|
cmp = PyObject_RichCompareBool(x, y, op);
|
|
|
|
Py_DECREF(x);
|
|
|
|
Py_DECREF(y);
|
|
|
|
goto done;
|
|
|
|
}
|
|
|
|
Py_DECREF(x);
|
|
|
|
Py_DECREF(y);
|
|
|
|
if (b == -1)
|
|
|
|
goto done;
|
|
|
|
}
|
Upon insertion, if memory runs out, the deque was left in a corrupted state.
deque_item(): a performance bug: the linked list of blocks was followed
from the left in most cases, because the test (i < (deque->len >> 1)) was
after "i %= BLOCKLEN".
deque_clear(): replaced a call to deque_len() with deque->len; not sure what
this call was here for, nor if all compilers under the sun would inline it.
deque_traverse(): I belive that it could be called by the GC when the deque
has leftblock==rightblock==NULL, because it is tracked before the first block
is allocated (though closely before). Still, a C extension module subclassing
deque could provide its own tp_alloc that could trigger a GC collection after
the PyObject_GC_Track()...
deque_richcompare(): rewrote to cleanly check for end-of-iterations instead of
relying on deque.__iter__().next() to succeed exactly len(deque) times -- an
assumption which can break if deques are subclassed. Added a test.
I wonder if the length should be explicitely bounded to INT_MAX, with
OverflowErrors, as in listobject.c. On 64-bit machines, adding more than
INT_MAX in the deque will result in trouble. (Note to anyone/me fixing
this: carefully check for overflows if len is close to INT_MAX in the
following functions: deque_rotate(), deque_item(), deque_ass_item())
2004-10-02 21:59:34 +08:00
|
|
|
/* We reached the end of one deque or both */
|
|
|
|
Py_XDECREF(x);
|
|
|
|
Py_XDECREF(y);
|
|
|
|
if (PyErr_Occurred())
|
|
|
|
goto done;
|
2004-02-29 10:15:56 +08:00
|
|
|
switch (op) {
|
Upon insertion, if memory runs out, the deque was left in a corrupted state.
deque_item(): a performance bug: the linked list of blocks was followed
from the left in most cases, because the test (i < (deque->len >> 1)) was
after "i %= BLOCKLEN".
deque_clear(): replaced a call to deque_len() with deque->len; not sure what
this call was here for, nor if all compilers under the sun would inline it.
deque_traverse(): I belive that it could be called by the GC when the deque
has leftblock==rightblock==NULL, because it is tracked before the first block
is allocated (though closely before). Still, a C extension module subclassing
deque could provide its own tp_alloc that could trigger a GC collection after
the PyObject_GC_Track()...
deque_richcompare(): rewrote to cleanly check for end-of-iterations instead of
relying on deque.__iter__().next() to succeed exactly len(deque) times -- an
assumption which can break if deques are subclassed. Added a test.
I wonder if the length should be explicitely bounded to INT_MAX, with
OverflowErrors, as in listobject.c. On 64-bit machines, adding more than
INT_MAX in the deque will result in trouble. (Note to anyone/me fixing
this: carefully check for overflows if len is close to INT_MAX in the
following functions: deque_rotate(), deque_item(), deque_ass_item())
2004-10-02 21:59:34 +08:00
|
|
|
case Py_LT: cmp = y != NULL; break; /* if w was longer */
|
|
|
|
case Py_LE: cmp = x == NULL; break; /* if v was not longer */
|
|
|
|
case Py_EQ: cmp = x == y; break; /* if we reached the end of both */
|
|
|
|
case Py_NE: cmp = x != y; break; /* if one deque continues */
|
|
|
|
case Py_GT: cmp = x != NULL; break; /* if v was longer */
|
|
|
|
case Py_GE: cmp = y == NULL; break; /* if w was not longer */
|
2004-02-29 10:15:56 +08:00
|
|
|
}
|
2004-10-01 09:03:29 +08:00
|
|
|
|
2004-02-29 10:15:56 +08:00
|
|
|
done:
|
|
|
|
Py_XDECREF(it1);
|
|
|
|
Py_XDECREF(it2);
|
|
|
|
if (cmp == 1)
|
|
|
|
Py_RETURN_TRUE;
|
|
|
|
if (cmp == 0)
|
|
|
|
Py_RETURN_FALSE;
|
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
|
2004-01-29 14:37:52 +08:00
|
|
|
static int
|
|
|
|
deque_init(dequeobject *deque, PyObject *args, PyObject *kwds)
|
|
|
|
{
|
2004-02-07 03:04:56 +08:00
|
|
|
PyObject *iterable = NULL;
|
2004-01-29 14:37:52 +08:00
|
|
|
|
|
|
|
if (!PyArg_UnpackTuple(args, "deque", 0, 1, &iterable))
|
|
|
|
return -1;
|
|
|
|
|
|
|
|
if (iterable != NULL) {
|
2004-02-07 03:04:56 +08:00
|
|
|
PyObject *rv = deque_extend(deque, iterable);
|
|
|
|
if (rv == NULL)
|
2004-01-29 14:37:52 +08:00
|
|
|
return -1;
|
2004-02-07 03:04:56 +08:00
|
|
|
Py_DECREF(rv);
|
2004-01-29 14:37:52 +08:00
|
|
|
}
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
static PySequenceMethods deque_as_sequence = {
|
|
|
|
(inquiry)deque_len, /* sq_length */
|
|
|
|
0, /* sq_concat */
|
2004-03-02 07:16:22 +08:00
|
|
|
0, /* sq_repeat */
|
|
|
|
(intargfunc)deque_item, /* sq_item */
|
|
|
|
0, /* sq_slice */
|
|
|
|
(intobjargproc)deque_ass_item, /* sq_ass_item */
|
2004-01-29 14:37:52 +08:00
|
|
|
};
|
|
|
|
|
|
|
|
/* deque object ********************************************************/
|
|
|
|
|
|
|
|
static PyObject *deque_iter(dequeobject *deque);
|
2004-03-18 19:04:57 +08:00
|
|
|
static PyObject *deque_reviter(dequeobject *deque);
|
2004-10-01 09:03:29 +08:00
|
|
|
PyDoc_STRVAR(reversed_doc,
|
2004-03-18 19:04:57 +08:00
|
|
|
"D.__reversed__() -- return a reverse iterator over the deque");
|
2004-01-29 14:37:52 +08:00
|
|
|
|
|
|
|
static PyMethodDef deque_methods[] = {
|
2004-10-01 09:03:29 +08:00
|
|
|
{"append", (PyCFunction)deque_append,
|
2004-01-29 14:37:52 +08:00
|
|
|
METH_O, append_doc},
|
2004-10-01 09:03:29 +08:00
|
|
|
{"appendleft", (PyCFunction)deque_appendleft,
|
2004-01-29 14:37:52 +08:00
|
|
|
METH_O, appendleft_doc},
|
2004-10-01 09:03:29 +08:00
|
|
|
{"clear", (PyCFunction)deque_clearmethod,
|
2004-01-29 14:37:52 +08:00
|
|
|
METH_NOARGS, clear_doc},
|
2004-10-01 09:03:29 +08:00
|
|
|
{"__copy__", (PyCFunction)deque_copy,
|
2004-01-29 14:37:52 +08:00
|
|
|
METH_NOARGS, copy_doc},
|
2004-10-01 09:03:29 +08:00
|
|
|
{"extend", (PyCFunction)deque_extend,
|
2004-02-08 05:13:00 +08:00
|
|
|
METH_O, extend_doc},
|
2004-10-01 09:03:29 +08:00
|
|
|
{"extendleft", (PyCFunction)deque_extendleft,
|
2004-02-08 05:13:00 +08:00
|
|
|
METH_O, extendleft_doc},
|
2004-10-01 09:03:29 +08:00
|
|
|
{"pop", (PyCFunction)deque_pop,
|
2004-01-29 14:37:52 +08:00
|
|
|
METH_NOARGS, pop_doc},
|
2004-10-01 09:03:29 +08:00
|
|
|
{"popleft", (PyCFunction)deque_popleft,
|
2004-01-29 14:37:52 +08:00
|
|
|
METH_NOARGS, popleft_doc},
|
2004-10-01 09:03:29 +08:00
|
|
|
{"__reduce__", (PyCFunction)deque_reduce,
|
2004-01-29 14:37:52 +08:00
|
|
|
METH_NOARGS, reduce_doc},
|
2004-10-01 09:03:29 +08:00
|
|
|
{"__reversed__", (PyCFunction)deque_reviter,
|
2004-03-18 19:04:57 +08:00
|
|
|
METH_NOARGS, reversed_doc},
|
2004-10-01 09:03:29 +08:00
|
|
|
{"rotate", (PyCFunction)deque_rotate,
|
2004-02-08 05:13:00 +08:00
|
|
|
METH_VARARGS, rotate_doc},
|
2004-01-29 14:37:52 +08:00
|
|
|
{NULL, NULL} /* sentinel */
|
|
|
|
};
|
|
|
|
|
|
|
|
PyDoc_STRVAR(deque_doc,
|
|
|
|
"deque(iterable) --> deque object\n\
|
|
|
|
\n\
|
|
|
|
Build an ordered collection accessible from endpoints only.");
|
|
|
|
|
2004-02-29 23:40:53 +08:00
|
|
|
static PyTypeObject deque_type = {
|
2004-01-29 14:37:52 +08:00
|
|
|
PyObject_HEAD_INIT(NULL)
|
|
|
|
0, /* ob_size */
|
|
|
|
"collections.deque", /* tp_name */
|
|
|
|
sizeof(dequeobject), /* tp_basicsize */
|
|
|
|
0, /* tp_itemsize */
|
|
|
|
/* methods */
|
|
|
|
(destructor)deque_dealloc, /* tp_dealloc */
|
|
|
|
(printfunc)deque_tp_print, /* tp_print */
|
|
|
|
0, /* tp_getattr */
|
|
|
|
0, /* tp_setattr */
|
|
|
|
0, /* tp_compare */
|
|
|
|
(reprfunc)deque_repr, /* tp_repr */
|
|
|
|
0, /* tp_as_number */
|
|
|
|
&deque_as_sequence, /* tp_as_sequence */
|
|
|
|
0, /* tp_as_mapping */
|
|
|
|
deque_nohash, /* tp_hash */
|
|
|
|
0, /* tp_call */
|
|
|
|
0, /* tp_str */
|
|
|
|
PyObject_GenericGetAttr, /* tp_getattro */
|
|
|
|
0, /* tp_setattro */
|
|
|
|
0, /* tp_as_buffer */
|
2004-05-30 15:26:47 +08:00
|
|
|
Py_TPFLAGS_DEFAULT | Py_TPFLAGS_BASETYPE | Py_TPFLAGS_HAVE_GC |
|
|
|
|
Py_TPFLAGS_HAVE_WEAKREFS, /* tp_flags */
|
2004-01-29 14:37:52 +08:00
|
|
|
deque_doc, /* tp_doc */
|
2004-03-02 07:16:22 +08:00
|
|
|
(traverseproc)deque_traverse, /* tp_traverse */
|
2004-01-29 14:37:52 +08:00
|
|
|
(inquiry)deque_clear, /* tp_clear */
|
2004-02-29 10:15:56 +08:00
|
|
|
(richcmpfunc)deque_richcompare, /* tp_richcompare */
|
2004-05-30 15:26:47 +08:00
|
|
|
offsetof(dequeobject, weakreflist), /* tp_weaklistoffset*/
|
2004-01-29 14:37:52 +08:00
|
|
|
(getiterfunc)deque_iter, /* tp_iter */
|
|
|
|
0, /* tp_iternext */
|
|
|
|
deque_methods, /* tp_methods */
|
|
|
|
0, /* tp_members */
|
|
|
|
0, /* tp_getset */
|
|
|
|
0, /* tp_base */
|
|
|
|
0, /* tp_dict */
|
|
|
|
0, /* tp_descr_get */
|
|
|
|
0, /* tp_descr_set */
|
|
|
|
0, /* tp_dictoffset */
|
|
|
|
(initproc)deque_init, /* tp_init */
|
|
|
|
PyType_GenericAlloc, /* tp_alloc */
|
|
|
|
deque_new, /* tp_new */
|
|
|
|
PyObject_GC_Del, /* tp_free */
|
|
|
|
};
|
|
|
|
|
|
|
|
/*********************** Deque Iterator **************************/
|
|
|
|
|
|
|
|
typedef struct {
|
|
|
|
PyObject_HEAD
|
|
|
|
int index;
|
|
|
|
block *b;
|
|
|
|
dequeobject *deque;
|
2004-10-02 08:43:13 +08:00
|
|
|
long state; /* state when the iterator is created */
|
|
|
|
int counter; /* number of items remaining for iteration */
|
2004-01-29 14:37:52 +08:00
|
|
|
} dequeiterobject;
|
|
|
|
|
|
|
|
PyTypeObject dequeiter_type;
|
|
|
|
|
|
|
|
static PyObject *
|
|
|
|
deque_iter(dequeobject *deque)
|
|
|
|
{
|
|
|
|
dequeiterobject *it;
|
|
|
|
|
|
|
|
it = PyObject_New(dequeiterobject, &dequeiter_type);
|
|
|
|
if (it == NULL)
|
|
|
|
return NULL;
|
|
|
|
it->b = deque->leftblock;
|
|
|
|
it->index = deque->leftindex;
|
|
|
|
Py_INCREF(deque);
|
|
|
|
it->deque = deque;
|
2004-10-02 08:43:13 +08:00
|
|
|
it->state = deque->state;
|
2004-03-18 19:04:57 +08:00
|
|
|
it->counter = deque->len;
|
2004-01-29 14:37:52 +08:00
|
|
|
return (PyObject *)it;
|
|
|
|
}
|
|
|
|
|
|
|
|
static void
|
|
|
|
dequeiter_dealloc(dequeiterobject *dio)
|
|
|
|
{
|
|
|
|
Py_XDECREF(dio->deque);
|
|
|
|
dio->ob_type->tp_free(dio);
|
|
|
|
}
|
|
|
|
|
|
|
|
static PyObject *
|
|
|
|
dequeiter_next(dequeiterobject *it)
|
|
|
|
{
|
|
|
|
PyObject *item;
|
2004-10-02 08:43:13 +08:00
|
|
|
|
|
|
|
if (it->counter == 0)
|
2004-01-29 14:37:52 +08:00
|
|
|
return NULL;
|
|
|
|
|
2004-10-02 08:43:13 +08:00
|
|
|
if (it->deque->state != it->state) {
|
2004-04-13 02:10:01 +08:00
|
|
|
it->counter = 0;
|
2004-01-29 14:37:52 +08:00
|
|
|
PyErr_SetString(PyExc_RuntimeError,
|
2004-10-02 08:43:13 +08:00
|
|
|
"deque mutated during iteration");
|
2004-01-29 14:37:52 +08:00
|
|
|
return NULL;
|
|
|
|
}
|
2004-10-02 08:43:13 +08:00
|
|
|
assert (!(it->b == it->deque->rightblock &&
|
|
|
|
it->index > it->deque->rightindex));
|
2004-01-29 14:37:52 +08:00
|
|
|
|
|
|
|
item = it->b->data[it->index];
|
|
|
|
it->index++;
|
2004-10-02 08:43:13 +08:00
|
|
|
it->counter--;
|
|
|
|
if (it->index == BLOCKLEN && it->counter > 0) {
|
|
|
|
assert (it->b->rightlink != NULL);
|
2004-01-29 14:37:52 +08:00
|
|
|
it->b = it->b->rightlink;
|
|
|
|
it->index = 0;
|
|
|
|
}
|
|
|
|
Py_INCREF(item);
|
|
|
|
return item;
|
|
|
|
}
|
|
|
|
|
2004-03-18 19:04:57 +08:00
|
|
|
static int
|
|
|
|
dequeiter_len(dequeiterobject *it)
|
|
|
|
{
|
|
|
|
return it->counter;
|
|
|
|
}
|
|
|
|
|
|
|
|
static PySequenceMethods dequeiter_as_sequence = {
|
|
|
|
(inquiry)dequeiter_len, /* sq_length */
|
|
|
|
0, /* sq_concat */
|
|
|
|
};
|
|
|
|
|
2004-01-29 14:37:52 +08:00
|
|
|
PyTypeObject dequeiter_type = {
|
|
|
|
PyObject_HEAD_INIT(NULL)
|
|
|
|
0, /* ob_size */
|
|
|
|
"deque_iterator", /* tp_name */
|
|
|
|
sizeof(dequeiterobject), /* tp_basicsize */
|
|
|
|
0, /* tp_itemsize */
|
|
|
|
/* methods */
|
|
|
|
(destructor)dequeiter_dealloc, /* tp_dealloc */
|
|
|
|
0, /* tp_print */
|
|
|
|
0, /* tp_getattr */
|
|
|
|
0, /* tp_setattr */
|
|
|
|
0, /* tp_compare */
|
|
|
|
0, /* tp_repr */
|
|
|
|
0, /* tp_as_number */
|
2004-03-18 19:04:57 +08:00
|
|
|
&dequeiter_as_sequence, /* tp_as_sequence */
|
2004-01-29 14:37:52 +08:00
|
|
|
0, /* tp_as_mapping */
|
|
|
|
0, /* tp_hash */
|
|
|
|
0, /* tp_call */
|
|
|
|
0, /* tp_str */
|
|
|
|
PyObject_GenericGetAttr, /* tp_getattro */
|
|
|
|
0, /* tp_setattro */
|
|
|
|
0, /* tp_as_buffer */
|
|
|
|
Py_TPFLAGS_DEFAULT, /* tp_flags */
|
|
|
|
0, /* tp_doc */
|
|
|
|
0, /* tp_traverse */
|
|
|
|
0, /* tp_clear */
|
|
|
|
0, /* tp_richcompare */
|
|
|
|
0, /* tp_weaklistoffset */
|
|
|
|
PyObject_SelfIter, /* tp_iter */
|
|
|
|
(iternextfunc)dequeiter_next, /* tp_iternext */
|
|
|
|
0,
|
|
|
|
};
|
|
|
|
|
2004-03-18 19:04:57 +08:00
|
|
|
/*********************** Deque Reverse Iterator **************************/
|
|
|
|
|
|
|
|
PyTypeObject dequereviter_type;
|
|
|
|
|
|
|
|
static PyObject *
|
|
|
|
deque_reviter(dequeobject *deque)
|
|
|
|
{
|
|
|
|
dequeiterobject *it;
|
|
|
|
|
|
|
|
it = PyObject_New(dequeiterobject, &dequereviter_type);
|
|
|
|
if (it == NULL)
|
|
|
|
return NULL;
|
|
|
|
it->b = deque->rightblock;
|
|
|
|
it->index = deque->rightindex;
|
|
|
|
Py_INCREF(deque);
|
|
|
|
it->deque = deque;
|
2004-10-02 08:43:13 +08:00
|
|
|
it->state = deque->state;
|
2004-03-18 19:04:57 +08:00
|
|
|
it->counter = deque->len;
|
|
|
|
return (PyObject *)it;
|
|
|
|
}
|
|
|
|
|
|
|
|
static PyObject *
|
|
|
|
dequereviter_next(dequeiterobject *it)
|
|
|
|
{
|
|
|
|
PyObject *item;
|
2004-10-02 08:43:13 +08:00
|
|
|
if (it->counter == 0)
|
2004-03-18 19:04:57 +08:00
|
|
|
return NULL;
|
|
|
|
|
2004-10-02 08:43:13 +08:00
|
|
|
if (it->deque->state != it->state) {
|
2004-04-13 02:10:01 +08:00
|
|
|
it->counter = 0;
|
2004-03-18 19:04:57 +08:00
|
|
|
PyErr_SetString(PyExc_RuntimeError,
|
2004-10-02 08:43:13 +08:00
|
|
|
"deque mutated during iteration");
|
2004-03-18 19:04:57 +08:00
|
|
|
return NULL;
|
|
|
|
}
|
2004-10-02 08:43:13 +08:00
|
|
|
assert (!(it->b == it->deque->leftblock &&
|
|
|
|
it->index < it->deque->leftindex));
|
2004-03-18 19:04:57 +08:00
|
|
|
|
|
|
|
item = it->b->data[it->index];
|
|
|
|
it->index--;
|
2004-10-02 08:43:13 +08:00
|
|
|
it->counter--;
|
|
|
|
if (it->index == -1 && it->counter > 0) {
|
|
|
|
assert (it->b->leftlink != NULL);
|
2004-03-18 19:04:57 +08:00
|
|
|
it->b = it->b->leftlink;
|
|
|
|
it->index = BLOCKLEN - 1;
|
|
|
|
}
|
|
|
|
Py_INCREF(item);
|
|
|
|
return item;
|
|
|
|
}
|
|
|
|
|
|
|
|
PyTypeObject dequereviter_type = {
|
|
|
|
PyObject_HEAD_INIT(NULL)
|
|
|
|
0, /* ob_size */
|
|
|
|
"deque_reverse_iterator", /* tp_name */
|
|
|
|
sizeof(dequeiterobject), /* tp_basicsize */
|
|
|
|
0, /* tp_itemsize */
|
|
|
|
/* methods */
|
|
|
|
(destructor)dequeiter_dealloc, /* tp_dealloc */
|
|
|
|
0, /* tp_print */
|
|
|
|
0, /* tp_getattr */
|
|
|
|
0, /* tp_setattr */
|
|
|
|
0, /* tp_compare */
|
|
|
|
0, /* tp_repr */
|
|
|
|
0, /* tp_as_number */
|
|
|
|
&dequeiter_as_sequence, /* tp_as_sequence */
|
|
|
|
0, /* tp_as_mapping */
|
|
|
|
0, /* tp_hash */
|
|
|
|
0, /* tp_call */
|
|
|
|
0, /* tp_str */
|
|
|
|
PyObject_GenericGetAttr, /* tp_getattro */
|
|
|
|
0, /* tp_setattro */
|
|
|
|
0, /* tp_as_buffer */
|
|
|
|
Py_TPFLAGS_DEFAULT, /* tp_flags */
|
|
|
|
0, /* tp_doc */
|
|
|
|
0, /* tp_traverse */
|
|
|
|
0, /* tp_clear */
|
|
|
|
0, /* tp_richcompare */
|
|
|
|
0, /* tp_weaklistoffset */
|
|
|
|
PyObject_SelfIter, /* tp_iter */
|
|
|
|
(iternextfunc)dequereviter_next, /* tp_iternext */
|
|
|
|
0,
|
|
|
|
};
|
|
|
|
|
2004-01-29 14:37:52 +08:00
|
|
|
/* module level code ********************************************************/
|
|
|
|
|
|
|
|
PyDoc_STRVAR(module_doc,
|
|
|
|
"High performance data structures\n\
|
|
|
|
");
|
|
|
|
|
|
|
|
PyMODINIT_FUNC
|
|
|
|
initcollections(void)
|
|
|
|
{
|
|
|
|
PyObject *m;
|
|
|
|
|
|
|
|
m = Py_InitModule3("collections", NULL, module_doc);
|
|
|
|
|
|
|
|
if (PyType_Ready(&deque_type) < 0)
|
|
|
|
return;
|
|
|
|
Py_INCREF(&deque_type);
|
|
|
|
PyModule_AddObject(m, "deque", (PyObject *)&deque_type);
|
|
|
|
|
|
|
|
if (PyType_Ready(&dequeiter_type) < 0)
|
2004-10-01 09:03:29 +08:00
|
|
|
return;
|
2004-01-29 14:37:52 +08:00
|
|
|
|
2004-03-18 19:04:57 +08:00
|
|
|
if (PyType_Ready(&dequereviter_type) < 0)
|
|
|
|
return;
|
|
|
|
|
2004-01-29 14:37:52 +08:00
|
|
|
return;
|
|
|
|
}
|