cpython/Objects/bufferobject.c

647 lines
15 KiB
C
Raw Normal View History

1998-10-07 14:36:10 +00:00
/* Buffer object implementation */
#include "Python.h"
typedef struct {
PyObject_HEAD
PyObject *b_base;
void *b_ptr;
2006-02-15 17:27:45 +00:00
Py_ssize_t b_size;
Py_ssize_t b_offset;
1998-10-07 14:36:10 +00:00
int b_readonly;
long b_hash;
} PyBufferObject;
static int
get_buf(PyBufferObject *self, PyBuffer *view, int flags)
{
if (self->b_base == NULL) {
view->buf = self->b_ptr;
view->len = self->b_size;
}
else {
2006-02-15 17:27:45 +00:00
Py_ssize_t count, offset;
PyBufferProcs *bp = self->b_base->ob_type->tp_as_buffer;
if ((*bp->bf_getbuffer)(self->b_base, view, flags) < 0) return 0;
count = view->len;
/* apply constraints to the start/end */
if (self->b_offset > count)
offset = count;
else
offset = self->b_offset;
view->buf = (char*)view->buf + offset;
if (self->b_size == Py_END_OF_BUFFER)
view->len = count;
else
view->len = self->b_size;
if (offset + view->len > count)
view->len = count - offset;
}
return 1;
}
static int
buffer_getbuf(PyBufferObject *self, PyBuffer *view, int flags)
{
if (view == NULL) return 0;
if (!get_buf(self, view, flags))
return -1;
return PyBuffer_FillInfo(view, view->buf, view->len, self->b_readonly, flags);
}
static void
buffer_releasebuf(PyBufferObject *self, PyBuffer *view)
{
/* No-op if there is no self->b_base */
if (self->b_base != NULL) {
PyBufferProcs *bp = self->b_base->ob_type->tp_as_buffer;
if (bp->bf_releasebuffer != NULL) {
(*bp->bf_releasebuffer)(self->b_base, view);
}
}
}
1998-10-07 14:36:10 +00:00
static PyObject *
2006-02-15 17:27:45 +00:00
buffer_from_memory(PyObject *base, Py_ssize_t size, Py_ssize_t offset, void *ptr,
int readonly)
1998-10-07 14:36:10 +00:00
{
PyBufferObject * b;
if (size < 0 && size != Py_END_OF_BUFFER) {
PyErr_SetString(PyExc_ValueError,
"size must be zero or positive");
return NULL;
}
if (offset < 0) {
PyErr_SetString(PyExc_ValueError,
"offset must be zero or positive");
return NULL;
}
1998-10-07 14:36:10 +00:00
b = PyObject_NEW(PyBufferObject, &PyBuffer_Type);
if ( b == NULL )
return NULL;
Py_XINCREF(base);
b->b_base = base;
b->b_ptr = ptr;
b->b_size = size;
b->b_offset = offset;
1998-10-07 14:36:10 +00:00
b->b_readonly = readonly;
b->b_hash = -1;
return (PyObject *) b;
}
static PyObject *
2006-02-15 17:27:45 +00:00
buffer_from_object(PyObject *base, Py_ssize_t size, Py_ssize_t offset, int readonly)
1998-10-07 14:36:10 +00:00
{
if (offset < 0) {
PyErr_SetString(PyExc_ValueError,
"offset must be zero or positive");
return NULL;
}
if ( PyBuffer_Check(base) && (((PyBufferObject *)base)->b_base) ) {
/* another buffer, refer to the base object */
PyBufferObject *b = (PyBufferObject *)base;
if (b->b_size != Py_END_OF_BUFFER) {
2006-02-15 17:27:45 +00:00
Py_ssize_t base_size = b->b_size - offset;
if (base_size < 0)
base_size = 0;
if (size == Py_END_OF_BUFFER || size > base_size)
size = base_size;
}
offset += b->b_offset;
base = b->b_base;
}
return buffer_from_memory(base, size, offset, NULL, readonly);
1998-10-07 14:36:10 +00:00
}
PyObject *
2006-02-15 17:27:45 +00:00
PyBuffer_FromObject(PyObject *base, Py_ssize_t offset, Py_ssize_t size)
1998-10-07 14:36:10 +00:00
{
PyBufferProcs *pb = base->ob_type->tp_as_buffer;
if ( pb == NULL ||
pb->bf_getbuffer == NULL) {
PyErr_SetString(PyExc_TypeError, "buffer object expected");
1998-10-07 14:36:10 +00:00
return NULL;
}
return buffer_from_object(base, size, offset, 1);
1998-10-07 14:36:10 +00:00
}
PyObject *
2006-02-15 17:27:45 +00:00
PyBuffer_FromReadWriteObject(PyObject *base, Py_ssize_t offset, Py_ssize_t size)
1998-10-07 14:36:10 +00:00
{
PyBufferProcs *pb = base->ob_type->tp_as_buffer;
if ( pb == NULL ||
pb->bf_getbuffer == NULL) {
1998-10-07 14:36:10 +00:00
PyErr_SetString(PyExc_TypeError, "buffer object expected");
return NULL;
}
return buffer_from_object(base, size, offset, 0);
1998-10-07 14:36:10 +00:00
}
PyObject *
2006-02-15 17:27:45 +00:00
PyBuffer_FromMemory(void *ptr, Py_ssize_t size)
1998-10-07 14:36:10 +00:00
{
return buffer_from_memory(NULL, size, 0, ptr, 1);
1998-10-07 14:36:10 +00:00
}
PyObject *
2006-02-15 17:27:45 +00:00
PyBuffer_FromReadWriteMemory(void *ptr, Py_ssize_t size)
1998-10-07 14:36:10 +00:00
{
return buffer_from_memory(NULL, size, 0, ptr, 0);
1998-10-07 14:36:10 +00:00
}
PyObject *
2006-02-15 17:27:45 +00:00
PyBuffer_New(Py_ssize_t size)
1998-10-07 14:36:10 +00:00
{
2000-08-04 15:36:13 +00:00
PyObject *o;
1998-10-07 14:36:10 +00:00
PyBufferObject * b;
if (size < 0) {
PyErr_SetString(PyExc_ValueError,
"size must be zero or positive");
return NULL;
}
2006-02-15 17:27:45 +00:00
/* XXX: check for overflow in multiply */
/* Inline PyObject_New */
o = (PyObject *)PyObject_MALLOC(sizeof(*b) + size);
2000-08-04 15:36:13 +00:00
if ( o == NULL )
return PyErr_NoMemory();
2000-08-04 15:36:13 +00:00
b = (PyBufferObject *) PyObject_INIT(o, &PyBuffer_Type);
1998-10-07 14:36:10 +00:00
b->b_base = NULL;
b->b_ptr = (void *)(b + 1);
b->b_size = size;
b->b_offset = 0;
1998-10-07 14:36:10 +00:00
b->b_readonly = 0;
b->b_hash = -1;
2000-08-04 15:36:13 +00:00
return o;
1998-10-07 14:36:10 +00:00
}
/* Methods */
static PyObject *
buffer_new(PyTypeObject *type, PyObject *args, PyObject *kw)
{
PyObject *ob;
2006-02-15 17:27:45 +00:00
Py_ssize_t offset = 0;
Py_ssize_t size = Py_END_OF_BUFFER;
if (!_PyArg_NoKeywords("buffer()", kw))
return NULL;
if (!PyArg_ParseTuple(args, "O|nn:buffer", &ob, &offset, &size))
return NULL;
return PyBuffer_FromObject(ob, offset, size);
}
PyDoc_STRVAR(buffer_doc,
"buffer(object [, offset[, size]])\n\
\n\
Create a new buffer object which references the given object.\n\
The buffer will reference a slice of the target object from the\n\
start of the object (or at the specified offset). The slice will\n\
extend to the end of the target object (or with the specified size).");
1998-10-07 14:36:10 +00:00
static void
2000-07-09 04:06:11 +00:00
buffer_dealloc(PyBufferObject *self)
1998-10-07 14:36:10 +00:00
{
Py_XDECREF(self->b_base);
PyObject_DEL(self);
1998-10-07 14:36:10 +00:00
}
static int
get_bufx(PyObject *obj, PyBuffer *view, int flags)
1998-10-07 14:36:10 +00:00
{
Restructure comparison dramatically. There is no longer a default *ordering* between objects; there is only a default equality test (defined by an object being equal to itself only). Read the comment in object.c. The current implementation never uses a three-way comparison to compute a rich comparison, but it does use a rich comparison to compute a three-way comparison. I'm not quite done ripping out all the calls to PyObject_Compare/Cmp, or replacing tp_compare implementations with tp_richcompare implementations; but much of that has happened (to make most unit tests pass). The following tests still fail, because I need help deciding or understanding: test_codeop -- depends on comparing code objects test_datetime -- need Tim Peters' opinion test_marshal -- depends on comparing code objects test_mutants -- need help understanding it The problem with test_codeop and test_marshal is this: these tests compare two different code objects and expect them to be equal. Is that still a feature we'd like to support? I've temporarily removed the comparison and hash code from code objects, so they use the default (equality by pointer only) comparison. For the other two tests, run them to see for yourself. (There may be more failing test with "-u all".) A general problem with getting lots of these tests to pass is the reality that for object types that have a natural total ordering, implementing __cmp__ is much more convenient than implementing __eq__, __ne__, __lt__, and so on. Should we go back to allowing __cmp__ to provide a total ordering? Should we provide some other way to implement rich comparison with a single method override? Alex proposed a __key__() method; I've considered a __richcmp__() method. Or perhaps __cmp__() just shouldn't be killed off...
2006-08-24 00:41:19 +00:00
PyBufferProcs *bp;
Restructure comparison dramatically. There is no longer a default *ordering* between objects; there is only a default equality test (defined by an object being equal to itself only). Read the comment in object.c. The current implementation never uses a three-way comparison to compute a rich comparison, but it does use a rich comparison to compute a three-way comparison. I'm not quite done ripping out all the calls to PyObject_Compare/Cmp, or replacing tp_compare implementations with tp_richcompare implementations; but much of that has happened (to make most unit tests pass). The following tests still fail, because I need help deciding or understanding: test_codeop -- depends on comparing code objects test_datetime -- need Tim Peters' opinion test_marshal -- depends on comparing code objects test_mutants -- need help understanding it The problem with test_codeop and test_marshal is this: these tests compare two different code objects and expect them to be equal. Is that still a feature we'd like to support? I've temporarily removed the comparison and hash code from code objects, so they use the default (equality by pointer only) comparison. For the other two tests, run them to see for yourself. (There may be more failing test with "-u all".) A general problem with getting lots of these tests to pass is the reality that for object types that have a natural total ordering, implementing __cmp__ is much more convenient than implementing __eq__, __ne__, __lt__, and so on. Should we go back to allowing __cmp__ to provide a total ordering? Should we provide some other way to implement rich comparison with a single method override? Alex proposed a __key__() method; I've considered a __richcmp__() method. Or perhaps __cmp__() just shouldn't be killed off...
2006-08-24 00:41:19 +00:00
if (PyBuffer_Check(obj)) {
if (!get_buf((PyBufferObject *)obj, view, flags)) {
Restructure comparison dramatically. There is no longer a default *ordering* between objects; there is only a default equality test (defined by an object being equal to itself only). Read the comment in object.c. The current implementation never uses a three-way comparison to compute a rich comparison, but it does use a rich comparison to compute a three-way comparison. I'm not quite done ripping out all the calls to PyObject_Compare/Cmp, or replacing tp_compare implementations with tp_richcompare implementations; but much of that has happened (to make most unit tests pass). The following tests still fail, because I need help deciding or understanding: test_codeop -- depends on comparing code objects test_datetime -- need Tim Peters' opinion test_marshal -- depends on comparing code objects test_mutants -- need help understanding it The problem with test_codeop and test_marshal is this: these tests compare two different code objects and expect them to be equal. Is that still a feature we'd like to support? I've temporarily removed the comparison and hash code from code objects, so they use the default (equality by pointer only) comparison. For the other two tests, run them to see for yourself. (There may be more failing test with "-u all".) A general problem with getting lots of these tests to pass is the reality that for object types that have a natural total ordering, implementing __cmp__ is much more convenient than implementing __eq__, __ne__, __lt__, and so on. Should we go back to allowing __cmp__ to provide a total ordering? Should we provide some other way to implement rich comparison with a single method override? Alex proposed a __key__() method; I've considered a __richcmp__() method. Or perhaps __cmp__() just shouldn't be killed off...
2006-08-24 00:41:19 +00:00
PyErr_Clear();
return 0;
}
else
return 1;
}
bp = obj->ob_type->tp_as_buffer;
if (bp == NULL ||
bp->bf_getbuffer == NULL)
Restructure comparison dramatically. There is no longer a default *ordering* between objects; there is only a default equality test (defined by an object being equal to itself only). Read the comment in object.c. The current implementation never uses a three-way comparison to compute a rich comparison, but it does use a rich comparison to compute a three-way comparison. I'm not quite done ripping out all the calls to PyObject_Compare/Cmp, or replacing tp_compare implementations with tp_richcompare implementations; but much of that has happened (to make most unit tests pass). The following tests still fail, because I need help deciding or understanding: test_codeop -- depends on comparing code objects test_datetime -- need Tim Peters' opinion test_marshal -- depends on comparing code objects test_mutants -- need help understanding it The problem with test_codeop and test_marshal is this: these tests compare two different code objects and expect them to be equal. Is that still a feature we'd like to support? I've temporarily removed the comparison and hash code from code objects, so they use the default (equality by pointer only) comparison. For the other two tests, run them to see for yourself. (There may be more failing test with "-u all".) A general problem with getting lots of these tests to pass is the reality that for object types that have a natural total ordering, implementing __cmp__ is much more convenient than implementing __eq__, __ne__, __lt__, and so on. Should we go back to allowing __cmp__ to provide a total ordering? Should we provide some other way to implement rich comparison with a single method override? Alex proposed a __key__() method; I've considered a __richcmp__() method. Or perhaps __cmp__() just shouldn't be killed off...
2006-08-24 00:41:19 +00:00
return 0;
if ((*bp->bf_getbuffer)(obj, view, PyBUF_SIMPLE) < 0)
Restructure comparison dramatically. There is no longer a default *ordering* between objects; there is only a default equality test (defined by an object being equal to itself only). Read the comment in object.c. The current implementation never uses a three-way comparison to compute a rich comparison, but it does use a rich comparison to compute a three-way comparison. I'm not quite done ripping out all the calls to PyObject_Compare/Cmp, or replacing tp_compare implementations with tp_richcompare implementations; but much of that has happened (to make most unit tests pass). The following tests still fail, because I need help deciding or understanding: test_codeop -- depends on comparing code objects test_datetime -- need Tim Peters' opinion test_marshal -- depends on comparing code objects test_mutants -- need help understanding it The problem with test_codeop and test_marshal is this: these tests compare two different code objects and expect them to be equal. Is that still a feature we'd like to support? I've temporarily removed the comparison and hash code from code objects, so they use the default (equality by pointer only) comparison. For the other two tests, run them to see for yourself. (There may be more failing test with "-u all".) A general problem with getting lots of these tests to pass is the reality that for object types that have a natural total ordering, implementing __cmp__ is much more convenient than implementing __eq__, __ne__, __lt__, and so on. Should we go back to allowing __cmp__ to provide a total ordering? Should we provide some other way to implement rich comparison with a single method override? Alex proposed a __key__() method; I've considered a __richcmp__() method. Or perhaps __cmp__() just shouldn't be killed off...
2006-08-24 00:41:19 +00:00
return 0;
return 1;
Restructure comparison dramatically. There is no longer a default *ordering* between objects; there is only a default equality test (defined by an object being equal to itself only). Read the comment in object.c. The current implementation never uses a three-way comparison to compute a rich comparison, but it does use a rich comparison to compute a three-way comparison. I'm not quite done ripping out all the calls to PyObject_Compare/Cmp, or replacing tp_compare implementations with tp_richcompare implementations; but much of that has happened (to make most unit tests pass). The following tests still fail, because I need help deciding or understanding: test_codeop -- depends on comparing code objects test_datetime -- need Tim Peters' opinion test_marshal -- depends on comparing code objects test_mutants -- need help understanding it The problem with test_codeop and test_marshal is this: these tests compare two different code objects and expect them to be equal. Is that still a feature we'd like to support? I've temporarily removed the comparison and hash code from code objects, so they use the default (equality by pointer only) comparison. For the other two tests, run them to see for yourself. (There may be more failing test with "-u all".) A general problem with getting lots of these tests to pass is the reality that for object types that have a natural total ordering, implementing __cmp__ is much more convenient than implementing __eq__, __ne__, __lt__, and so on. Should we go back to allowing __cmp__ to provide a total ordering? Should we provide some other way to implement rich comparison with a single method override? Alex proposed a __key__() method; I've considered a __richcmp__() method. Or perhaps __cmp__() just shouldn't be killed off...
2006-08-24 00:41:19 +00:00
}
static PyObject *
buffer_richcompare(PyObject *self, PyObject *other, int op)
{
void *p1, *p2;
Py_ssize_t len1, len2, min_len;
int cmp, ok;
PyBuffer v1, v2;
Restructure comparison dramatically. There is no longer a default *ordering* between objects; there is only a default equality test (defined by an object being equal to itself only). Read the comment in object.c. The current implementation never uses a three-way comparison to compute a rich comparison, but it does use a rich comparison to compute a three-way comparison. I'm not quite done ripping out all the calls to PyObject_Compare/Cmp, or replacing tp_compare implementations with tp_richcompare implementations; but much of that has happened (to make most unit tests pass). The following tests still fail, because I need help deciding or understanding: test_codeop -- depends on comparing code objects test_datetime -- need Tim Peters' opinion test_marshal -- depends on comparing code objects test_mutants -- need help understanding it The problem with test_codeop and test_marshal is this: these tests compare two different code objects and expect them to be equal. Is that still a feature we'd like to support? I've temporarily removed the comparison and hash code from code objects, so they use the default (equality by pointer only) comparison. For the other two tests, run them to see for yourself. (There may be more failing test with "-u all".) A general problem with getting lots of these tests to pass is the reality that for object types that have a natural total ordering, implementing __cmp__ is much more convenient than implementing __eq__, __ne__, __lt__, and so on. Should we go back to allowing __cmp__ to provide a total ordering? Should we provide some other way to implement rich comparison with a single method override? Alex proposed a __key__() method; I've considered a __richcmp__() method. Or perhaps __cmp__() just shouldn't be killed off...
2006-08-24 00:41:19 +00:00
ok = 1;
if (!get_bufx(self, &v1, PyBUF_SIMPLE))
Restructure comparison dramatically. There is no longer a default *ordering* between objects; there is only a default equality test (defined by an object being equal to itself only). Read the comment in object.c. The current implementation never uses a three-way comparison to compute a rich comparison, but it does use a rich comparison to compute a three-way comparison. I'm not quite done ripping out all the calls to PyObject_Compare/Cmp, or replacing tp_compare implementations with tp_richcompare implementations; but much of that has happened (to make most unit tests pass). The following tests still fail, because I need help deciding or understanding: test_codeop -- depends on comparing code objects test_datetime -- need Tim Peters' opinion test_marshal -- depends on comparing code objects test_mutants -- need help understanding it The problem with test_codeop and test_marshal is this: these tests compare two different code objects and expect them to be equal. Is that still a feature we'd like to support? I've temporarily removed the comparison and hash code from code objects, so they use the default (equality by pointer only) comparison. For the other two tests, run them to see for yourself. (There may be more failing test with "-u all".) A general problem with getting lots of these tests to pass is the reality that for object types that have a natural total ordering, implementing __cmp__ is much more convenient than implementing __eq__, __ne__, __lt__, and so on. Should we go back to allowing __cmp__ to provide a total ordering? Should we provide some other way to implement rich comparison with a single method override? Alex proposed a __key__() method; I've considered a __richcmp__() method. Or perhaps __cmp__() just shouldn't be killed off...
2006-08-24 00:41:19 +00:00
ok = 0;
if (!get_bufx(other, &v2, PyBUF_SIMPLE)) {
if (ok) PyObject_ReleaseBuffer((PyObject *)self, &v1);
Restructure comparison dramatically. There is no longer a default *ordering* between objects; there is only a default equality test (defined by an object being equal to itself only). Read the comment in object.c. The current implementation never uses a three-way comparison to compute a rich comparison, but it does use a rich comparison to compute a three-way comparison. I'm not quite done ripping out all the calls to PyObject_Compare/Cmp, or replacing tp_compare implementations with tp_richcompare implementations; but much of that has happened (to make most unit tests pass). The following tests still fail, because I need help deciding or understanding: test_codeop -- depends on comparing code objects test_datetime -- need Tim Peters' opinion test_marshal -- depends on comparing code objects test_mutants -- need help understanding it The problem with test_codeop and test_marshal is this: these tests compare two different code objects and expect them to be equal. Is that still a feature we'd like to support? I've temporarily removed the comparison and hash code from code objects, so they use the default (equality by pointer only) comparison. For the other two tests, run them to see for yourself. (There may be more failing test with "-u all".) A general problem with getting lots of these tests to pass is the reality that for object types that have a natural total ordering, implementing __cmp__ is much more convenient than implementing __eq__, __ne__, __lt__, and so on. Should we go back to allowing __cmp__ to provide a total ordering? Should we provide some other way to implement rich comparison with a single method override? Alex proposed a __key__() method; I've considered a __richcmp__() method. Or perhaps __cmp__() just shouldn't be killed off...
2006-08-24 00:41:19 +00:00
ok = 0;
}
Restructure comparison dramatically. There is no longer a default *ordering* between objects; there is only a default equality test (defined by an object being equal to itself only). Read the comment in object.c. The current implementation never uses a three-way comparison to compute a rich comparison, but it does use a rich comparison to compute a three-way comparison. I'm not quite done ripping out all the calls to PyObject_Compare/Cmp, or replacing tp_compare implementations with tp_richcompare implementations; but much of that has happened (to make most unit tests pass). The following tests still fail, because I need help deciding or understanding: test_codeop -- depends on comparing code objects test_datetime -- need Tim Peters' opinion test_marshal -- depends on comparing code objects test_mutants -- need help understanding it The problem with test_codeop and test_marshal is this: these tests compare two different code objects and expect them to be equal. Is that still a feature we'd like to support? I've temporarily removed the comparison and hash code from code objects, so they use the default (equality by pointer only) comparison. For the other two tests, run them to see for yourself. (There may be more failing test with "-u all".) A general problem with getting lots of these tests to pass is the reality that for object types that have a natural total ordering, implementing __cmp__ is much more convenient than implementing __eq__, __ne__, __lt__, and so on. Should we go back to allowing __cmp__ to provide a total ordering? Should we provide some other way to implement rich comparison with a single method override? Alex proposed a __key__() method; I've considered a __richcmp__() method. Or perhaps __cmp__() just shouldn't be killed off...
2006-08-24 00:41:19 +00:00
if (!ok) {
/* If we can't get the buffers,
== and != are still defined
(and the objects are unequal) */
PyObject *result;
if (op == Py_EQ)
result = Py_False;
else if (op == Py_NE)
result = Py_True;
else
result = Py_NotImplemented;
Py_INCREF(result);
return result;
1998-10-07 14:36:10 +00:00
}
len1 = v1.len;
len2 = v2.len;
p1 = v1.buf;
p2 = v2.buf;
Restructure comparison dramatically. There is no longer a default *ordering* between objects; there is only a default equality test (defined by an object being equal to itself only). Read the comment in object.c. The current implementation never uses a three-way comparison to compute a rich comparison, but it does use a rich comparison to compute a three-way comparison. I'm not quite done ripping out all the calls to PyObject_Compare/Cmp, or replacing tp_compare implementations with tp_richcompare implementations; but much of that has happened (to make most unit tests pass). The following tests still fail, because I need help deciding or understanding: test_codeop -- depends on comparing code objects test_datetime -- need Tim Peters' opinion test_marshal -- depends on comparing code objects test_mutants -- need help understanding it The problem with test_codeop and test_marshal is this: these tests compare two different code objects and expect them to be equal. Is that still a feature we'd like to support? I've temporarily removed the comparison and hash code from code objects, so they use the default (equality by pointer only) comparison. For the other two tests, run them to see for yourself. (There may be more failing test with "-u all".) A general problem with getting lots of these tests to pass is the reality that for object types that have a natural total ordering, implementing __cmp__ is much more convenient than implementing __eq__, __ne__, __lt__, and so on. Should we go back to allowing __cmp__ to provide a total ordering? Should we provide some other way to implement rich comparison with a single method override? Alex proposed a __key__() method; I've considered a __richcmp__() method. Or perhaps __cmp__() just shouldn't be killed off...
2006-08-24 00:41:19 +00:00
min_len = (len1 < len2) ? len1 : len2;
cmp = memcmp(p1, p2, min_len);
if (cmp == 0)
cmp = (len1 < len2) ? -1 :
(len1 > len2) ? 1 : 0;
PyObject_ReleaseBuffer((PyObject *)self, &v1);
PyObject_ReleaseBuffer(other, &v2);
Restructure comparison dramatically. There is no longer a default *ordering* between objects; there is only a default equality test (defined by an object being equal to itself only). Read the comment in object.c. The current implementation never uses a three-way comparison to compute a rich comparison, but it does use a rich comparison to compute a three-way comparison. I'm not quite done ripping out all the calls to PyObject_Compare/Cmp, or replacing tp_compare implementations with tp_richcompare implementations; but much of that has happened (to make most unit tests pass). The following tests still fail, because I need help deciding or understanding: test_codeop -- depends on comparing code objects test_datetime -- need Tim Peters' opinion test_marshal -- depends on comparing code objects test_mutants -- need help understanding it The problem with test_codeop and test_marshal is this: these tests compare two different code objects and expect them to be equal. Is that still a feature we'd like to support? I've temporarily removed the comparison and hash code from code objects, so they use the default (equality by pointer only) comparison. For the other two tests, run them to see for yourself. (There may be more failing test with "-u all".) A general problem with getting lots of these tests to pass is the reality that for object types that have a natural total ordering, implementing __cmp__ is much more convenient than implementing __eq__, __ne__, __lt__, and so on. Should we go back to allowing __cmp__ to provide a total ordering? Should we provide some other way to implement rich comparison with a single method override? Alex proposed a __key__() method; I've considered a __richcmp__() method. Or perhaps __cmp__() just shouldn't be killed off...
2006-08-24 00:41:19 +00:00
return Py_CmpToRich(op, cmp);
1998-10-07 14:36:10 +00:00
}
static PyObject *
2000-07-09 04:06:11 +00:00
buffer_repr(PyBufferObject *self)
1998-10-07 14:36:10 +00:00
{
2006-02-15 17:27:45 +00:00
const char *status = self->b_readonly ? "read-only" : "read-write";
1998-10-07 14:36:10 +00:00
if ( self->b_base == NULL )
return PyUnicode_FromFormat("<%s buffer ptr %p, size %zd at %p>",
status,
self->b_ptr,
2006-02-16 06:59:22 +00:00
self->b_size,
self);
1998-10-07 14:36:10 +00:00
else
return PyUnicode_FromFormat(
"<%s buffer for %p, size %zd, offset %zd at %p>",
1998-10-07 14:36:10 +00:00
status,
self->b_base,
2006-02-16 06:59:22 +00:00
self->b_size,
self->b_offset,
self);
1998-10-07 14:36:10 +00:00
}
static long
2000-07-09 04:06:11 +00:00
buffer_hash(PyBufferObject *self)
1998-10-07 14:36:10 +00:00
{
PyBuffer view;
2006-02-15 17:27:45 +00:00
register Py_ssize_t len;
1998-10-07 14:36:10 +00:00
register unsigned char *p;
register long x;
if ( self->b_hash != -1 )
return self->b_hash;
if (!get_buf(self, &view, PyBUF_SIMPLE))
1998-10-07 14:36:10 +00:00
return -1;
if (!(self->b_readonly)) {
PyErr_SetString(PyExc_TypeError,
"writable buffers are not hashable");
PyObject_ReleaseBuffer((PyObject *)self, &view);
return -1;
}
p = (unsigned char *) view.buf;
len = view.len;
1998-10-07 14:36:10 +00:00
x = *p << 7;
while (--len >= 0)
x = (1000003*x) ^ *p++;
x ^= view.len;
1998-10-07 14:36:10 +00:00
if (x == -1)
x = -2;
self->b_hash = x;
PyObject_ReleaseBuffer((PyObject *)self, &view);
1998-10-07 14:36:10 +00:00
return x;
}
static PyObject *
2000-07-09 04:06:11 +00:00
buffer_str(PyBufferObject *self)
1998-10-07 14:36:10 +00:00
{
PyBuffer view;
PyObject *res;
if (!get_buf(self, &view, PyBUF_SIMPLE))
return NULL;
res = PyString_FromStringAndSize((const char *)view.buf, view.len);
PyObject_ReleaseBuffer((PyObject *)self, &view);
return res;
1998-10-07 14:36:10 +00:00
}
/* Sequence methods */
2006-02-15 17:27:45 +00:00
static Py_ssize_t
2000-07-09 04:06:11 +00:00
buffer_length(PyBufferObject *self)
1998-10-07 14:36:10 +00:00
{
PyBuffer view;
if (!get_buf(self, &view, PyBUF_SIMPLE))
return -1;
PyObject_ReleaseBuffer((PyObject *)self, &view);
return view.len;
1998-10-07 14:36:10 +00:00
}
static PyObject *
2000-07-09 04:06:11 +00:00
buffer_concat(PyBufferObject *self, PyObject *other)
1998-10-07 14:36:10 +00:00
{
PyBufferProcs *pb = other->ob_type->tp_as_buffer;
char *p;
1998-10-07 14:36:10 +00:00
PyObject *ob;
PyBuffer view, view2;
1998-10-07 14:36:10 +00:00
if ( pb == NULL ||
pb->bf_getbuffer == NULL)
1998-10-07 14:36:10 +00:00
{
PyErr_BadArgument();
return NULL;
}
if (!get_buf(self, &view, PyBUF_SIMPLE))
return NULL;
1998-10-07 14:36:10 +00:00
/* optimize special case */
/* XXX bad idea type-wise */
if ( view.len == 0 ) {
PyObject_ReleaseBuffer((PyObject *)self, &view);
Py_INCREF(other);
return other;
1998-10-07 14:36:10 +00:00
}
if (PyObject_GetBuffer((PyObject *)other, &view2, PyBUF_SIMPLE) < 0) {
PyObject_ReleaseBuffer((PyObject *)self, &view);
return NULL;
}
1998-10-07 14:36:10 +00:00
/* XXX(nnorwitz): need to check for overflow! */
ob = PyBytes_FromStringAndSize(NULL, view.len+view2.len);
if ( ob == NULL ) {
PyObject_ReleaseBuffer((PyObject *)self, &view);
PyObject_ReleaseBuffer(other, &view2);
2005-12-18 08:02:38 +00:00
return NULL;
}
p = PyBytes_AS_STRING(ob);
memcpy(p, view.buf, view.len);
memcpy(p + view.len, view2.buf, view2.len);
PyObject_ReleaseBuffer((PyObject *)self, &view);
PyObject_ReleaseBuffer(other, &view2);
return ob;
1998-10-07 14:36:10 +00:00
}
static PyObject *
2006-02-15 17:27:45 +00:00
buffer_repeat(PyBufferObject *self, Py_ssize_t count)
1998-10-07 14:36:10 +00:00
{
PyObject *ob;
register char *p;
PyBuffer view;
1998-10-07 14:36:10 +00:00
if ( count < 0 )
count = 0;
if (!get_buf(self, &view, PyBUF_SIMPLE))
return NULL;
/* XXX(nnorwitz): need to check for overflow! */
ob = PyBytes_FromStringAndSize(NULL, view.len * count);
1998-10-07 14:36:10 +00:00
if ( ob == NULL )
return NULL;
p = PyBytes_AS_STRING(ob);
1998-10-07 14:36:10 +00:00
while ( count-- )
{
memcpy(p, view.buf, view.len);
p += view.len;
1998-10-07 14:36:10 +00:00
}
PyObject_ReleaseBuffer((PyObject *)self, &view);
1998-10-07 14:36:10 +00:00
return ob;
}
static PyObject *
2006-02-15 17:27:45 +00:00
buffer_item(PyBufferObject *self, Py_ssize_t idx)
1998-10-07 14:36:10 +00:00
{
PyBuffer view;
PyObject *ob;
if (!get_buf(self, &view, PyBUF_SIMPLE))
return NULL;
if ( idx < 0 || idx >= view.len ) {
1998-10-07 14:36:10 +00:00
PyErr_SetString(PyExc_IndexError, "buffer index out of range");
return NULL;
}
ob = PyBytes_FromStringAndSize((char *)view.buf + idx, 1);
PyObject_ReleaseBuffer((PyObject *)self, &view);
return ob;
1998-10-07 14:36:10 +00:00
}
static PyObject *
2006-02-15 17:27:45 +00:00
buffer_slice(PyBufferObject *self, Py_ssize_t left, Py_ssize_t right)
1998-10-07 14:36:10 +00:00
{
PyObject *ob;
PyBuffer view;
if (!get_buf(self, &view, PyBUF_SIMPLE))
return NULL;
1998-10-07 14:36:10 +00:00
if ( left < 0 )
left = 0;
if ( right < 0 )
right = 0;
if ( right > view.len )
right = view.len;
1998-10-07 14:36:10 +00:00
if ( right < left )
right = left;
/* XXX(nnorwitz): is it possible to access unitialized memory? */
ob = PyBytes_FromStringAndSize((char *)view.buf + left,
right - left);
PyObject_ReleaseBuffer((PyObject *)self, &view);
return ob;
1998-10-07 14:36:10 +00:00
}
static int
2006-02-15 17:27:45 +00:00
buffer_ass_item(PyBufferObject *self, Py_ssize_t idx, PyObject *other)
1998-10-07 14:36:10 +00:00
{
PyBufferProcs *pb;
PyBuffer view, view2;
1998-10-07 14:36:10 +00:00
if (!get_buf(self, &view, PyBUF_SIMPLE))
return -1;
if ( self->b_readonly || view.readonly ) {
1998-10-07 14:36:10 +00:00
PyErr_SetString(PyExc_TypeError,
"buffer is read-only");
PyObject_ReleaseBuffer((PyObject *)self, &view);
1998-10-07 14:36:10 +00:00
return -1;
}
if (idx < 0 || idx >= view.len) {
PyObject_ReleaseBuffer((PyObject *)self, &view);
1998-10-07 14:36:10 +00:00
PyErr_SetString(PyExc_IndexError,
"buffer assignment index out of range");
return -1;
}
pb = other ? other->ob_type->tp_as_buffer : NULL;
if ( pb == NULL ||
pb->bf_getbuffer == NULL) {
1998-10-07 14:36:10 +00:00
PyErr_BadArgument();
PyObject_ReleaseBuffer((PyObject *)self, &view);
1998-10-07 14:36:10 +00:00
return -1;
}
if (PyObject_GetBuffer(other, &view2, PyBUF_SIMPLE) < 0) {
PyObject_ReleaseBuffer((PyObject *)self, &view);
return -1;
}
if ( view.len != 1 ) {
PyObject_ReleaseBuffer((PyObject *)self, &view);
PyObject_ReleaseBuffer(other, &view2);
1998-10-07 14:36:10 +00:00
PyErr_SetString(PyExc_TypeError,
"right operand must be a single byte");
return -1;
}
((char *)(view.buf))[idx] = *((char *)(view2.buf));
PyObject_ReleaseBuffer((PyObject *)self, &view);
PyObject_ReleaseBuffer(other, &view2);
1998-10-07 14:36:10 +00:00
return 0;
}
static int
2006-02-15 17:27:45 +00:00
buffer_ass_slice(PyBufferObject *self, Py_ssize_t left, Py_ssize_t right, PyObject *other)
1998-10-07 14:36:10 +00:00
{
PyBufferProcs *pb;
PyBuffer v1, v2;
2006-02-15 17:27:45 +00:00
Py_ssize_t slice_len;
1998-10-07 14:36:10 +00:00
pb = other ? other->ob_type->tp_as_buffer : NULL;
if ( pb == NULL ||
pb->bf_getbuffer == NULL)
1998-10-07 14:36:10 +00:00
{
PyErr_BadArgument();
return -1;
}
if (!get_buf(self, &v1, PyBUF_SIMPLE))
return -1;
if ( self->b_readonly || v1.readonly) {
1999-03-24 19:05:31 +00:00
PyErr_SetString(PyExc_TypeError,
"buffer is read-only");
PyObject_ReleaseBuffer((PyObject *)self, &v1);
1998-10-07 14:36:10 +00:00
return -1;
}
if ((*pb->bf_getbuffer)(other, &v2, PyBUF_SIMPLE) < 0) {
PyObject_ReleaseBuffer((PyObject *)self, &v1);
return -1;
}
1998-10-07 14:36:10 +00:00
if ( left < 0 )
left = 0;
else if ( left > v1.len )
left = v1.len;
1998-10-07 14:36:10 +00:00
if ( right < left )
right = left;
else if ( right > v1.len )
right = v1.len;
1998-10-07 14:36:10 +00:00
slice_len = right - left;
if ( v2.len != slice_len ) {
1999-03-24 19:05:31 +00:00
PyErr_SetString(
PyExc_TypeError,
"right operand length must match slice length");
PyObject_ReleaseBuffer((PyObject *)self, &v1);
PyObject_ReleaseBuffer(other, &v2);
1998-10-07 14:36:10 +00:00
return -1;
}
if ( slice_len )
memcpy((char *)v1.buf + left, v2.buf, slice_len);
1998-10-07 14:36:10 +00:00
PyObject_ReleaseBuffer((PyObject *)self, &v1);
PyObject_ReleaseBuffer(other, &v2);
1998-10-07 14:36:10 +00:00
return 0;
}
/* Buffer methods */
static PySequenceMethods buffer_as_sequence = {
2006-02-15 17:27:45 +00:00
(lenfunc)buffer_length, /*sq_length*/
1998-10-07 14:36:10 +00:00
(binaryfunc)buffer_concat, /*sq_concat*/
2006-02-15 17:27:45 +00:00
(ssizeargfunc)buffer_repeat, /*sq_repeat*/
(ssizeargfunc)buffer_item, /*sq_item*/
(ssizessizeargfunc)buffer_slice, /*sq_slice*/
(ssizeobjargproc)buffer_ass_item, /*sq_ass_item*/
(ssizessizeobjargproc)buffer_ass_slice, /*sq_ass_slice*/
1998-10-07 14:36:10 +00:00
};
static PyBufferProcs buffer_as_buffer = {
(getbufferproc)buffer_getbuf,
(releasebufferproc)buffer_releasebuf,
1998-10-07 14:36:10 +00:00
};
PyTypeObject PyBuffer_Type = {
PyVarObject_HEAD_INIT(&PyType_Type, 0)
1998-10-07 14:36:10 +00:00
"buffer",
sizeof(PyBufferObject),
0,
2001-08-02 04:15:00 +00:00
(destructor)buffer_dealloc, /* tp_dealloc */
0, /* tp_print */
0, /* tp_getattr */
0, /* tp_setattr */
Restructure comparison dramatically. There is no longer a default *ordering* between objects; there is only a default equality test (defined by an object being equal to itself only). Read the comment in object.c. The current implementation never uses a three-way comparison to compute a rich comparison, but it does use a rich comparison to compute a three-way comparison. I'm not quite done ripping out all the calls to PyObject_Compare/Cmp, or replacing tp_compare implementations with tp_richcompare implementations; but much of that has happened (to make most unit tests pass). The following tests still fail, because I need help deciding or understanding: test_codeop -- depends on comparing code objects test_datetime -- need Tim Peters' opinion test_marshal -- depends on comparing code objects test_mutants -- need help understanding it The problem with test_codeop and test_marshal is this: these tests compare two different code objects and expect them to be equal. Is that still a feature we'd like to support? I've temporarily removed the comparison and hash code from code objects, so they use the default (equality by pointer only) comparison. For the other two tests, run them to see for yourself. (There may be more failing test with "-u all".) A general problem with getting lots of these tests to pass is the reality that for object types that have a natural total ordering, implementing __cmp__ is much more convenient than implementing __eq__, __ne__, __lt__, and so on. Should we go back to allowing __cmp__ to provide a total ordering? Should we provide some other way to implement rich comparison with a single method override? Alex proposed a __key__() method; I've considered a __richcmp__() method. Or perhaps __cmp__() just shouldn't be killed off...
2006-08-24 00:41:19 +00:00
0, /* tp_compare */
2001-08-02 04:15:00 +00:00
(reprfunc)buffer_repr, /* tp_repr */
0, /* tp_as_number */
&buffer_as_sequence, /* tp_as_sequence */
0, /* tp_as_mapping */
(hashfunc)buffer_hash, /* tp_hash */
0, /* tp_call */
(reprfunc)buffer_str, /* tp_str */
PyObject_GenericGetAttr, /* tp_getattro */
0, /* tp_setattro */
&buffer_as_buffer, /* tp_as_buffer */
Py_TPFLAGS_DEFAULT, /* tp_flags */
buffer_doc, /* tp_doc */
0, /* tp_traverse */
0, /* tp_clear */
Restructure comparison dramatically. There is no longer a default *ordering* between objects; there is only a default equality test (defined by an object being equal to itself only). Read the comment in object.c. The current implementation never uses a three-way comparison to compute a rich comparison, but it does use a rich comparison to compute a three-way comparison. I'm not quite done ripping out all the calls to PyObject_Compare/Cmp, or replacing tp_compare implementations with tp_richcompare implementations; but much of that has happened (to make most unit tests pass). The following tests still fail, because I need help deciding or understanding: test_codeop -- depends on comparing code objects test_datetime -- need Tim Peters' opinion test_marshal -- depends on comparing code objects test_mutants -- need help understanding it The problem with test_codeop and test_marshal is this: these tests compare two different code objects and expect them to be equal. Is that still a feature we'd like to support? I've temporarily removed the comparison and hash code from code objects, so they use the default (equality by pointer only) comparison. For the other two tests, run them to see for yourself. (There may be more failing test with "-u all".) A general problem with getting lots of these tests to pass is the reality that for object types that have a natural total ordering, implementing __cmp__ is much more convenient than implementing __eq__, __ne__, __lt__, and so on. Should we go back to allowing __cmp__ to provide a total ordering? Should we provide some other way to implement rich comparison with a single method override? Alex proposed a __key__() method; I've considered a __richcmp__() method. Or perhaps __cmp__() just shouldn't be killed off...
2006-08-24 00:41:19 +00:00
buffer_richcompare, /* tp_richcompare */
0, /* tp_weaklistoffset */
0, /* tp_iter */
0, /* tp_iternext */
0, /* 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 */
0, /* tp_init */
0, /* tp_alloc */
buffer_new, /* tp_new */
1998-10-07 14:36:10 +00:00
};