cpython/Objects/methodobject.c

340 lines
7.5 KiB
C
Raw Normal View History

1991-02-19 08:39:46 -04:00
1990-10-14 09:07:46 -03:00
/* Method object implementation */
1997-05-02 00:12:38 -03:00
#include "Python.h"
#include "structmember.h"
1990-10-14 09:07:46 -03:00
static PyCFunctionObject *free_list = NULL;
1997-05-02 00:12:38 -03:00
PyObject *
PyCFunction_NewEx(PyMethodDef *ml, PyObject *self, PyObject *module)
1990-10-14 09:07:46 -03:00
{
PyCFunctionObject *op;
op = free_list;
1990-10-14 09:07:46 -03:00
if (op != NULL) {
free_list = (PyCFunctionObject *)(op->m_self);
PyObject_INIT(op, &PyCFunction_Type);
1990-10-14 09:07:46 -03:00
}
else {
2002-03-18 16:44:53 -04:00
op = PyObject_GC_New(PyCFunctionObject, &PyCFunction_Type);
if (op == NULL)
return NULL;
}
op->m_ml = ml;
Py_XINCREF(self);
op->m_self = self;
Py_XINCREF(module);
op->m_module = module;
2002-03-18 16:44:53 -04:00
_PyObject_GC_TRACK(op);
1997-05-02 00:12:38 -03:00
return (PyObject *)op;
1990-10-14 09:07:46 -03:00
}
1997-05-02 00:12:38 -03:00
PyCFunction
2000-07-09 03:03:25 -03:00
PyCFunction_GetFunction(PyObject *op)
1990-10-14 09:07:46 -03:00
{
1997-05-02 00:12:38 -03:00
if (!PyCFunction_Check(op)) {
PyErr_BadInternalCall();
1990-10-14 09:07:46 -03:00
return NULL;
}
1997-05-02 00:12:38 -03:00
return ((PyCFunctionObject *)op) -> m_ml -> ml_meth;
1990-10-14 09:07:46 -03:00
}
1997-05-02 00:12:38 -03:00
PyObject *
2000-07-09 03:03:25 -03:00
PyCFunction_GetSelf(PyObject *op)
1990-10-14 09:07:46 -03:00
{
1997-05-02 00:12:38 -03:00
if (!PyCFunction_Check(op)) {
PyErr_BadInternalCall();
1990-10-14 09:07:46 -03:00
return NULL;
}
1997-05-02 00:12:38 -03:00
return ((PyCFunctionObject *)op) -> m_self;
1990-10-14 09:07:46 -03:00
}
1991-12-16 09:07:24 -04:00
int
2000-07-09 03:03:25 -03:00
PyCFunction_GetFlags(PyObject *op)
1991-12-16 09:07:24 -04:00
{
1997-05-02 00:12:38 -03:00
if (!PyCFunction_Check(op)) {
PyErr_BadInternalCall();
1991-12-16 09:07:24 -04:00
return -1;
}
1997-05-02 00:12:38 -03:00
return ((PyCFunctionObject *)op) -> m_ml -> ml_flags;
1991-12-16 09:07:24 -04:00
}
PyObject *
PyCFunction_Call(PyObject *func, PyObject *arg, PyObject *kw)
{
PyCFunctionObject* f = (PyCFunctionObject*)func;
PyCFunction meth = PyCFunction_GET_FUNCTION(func);
PyObject *self = PyCFunction_GET_SELF(func);
Py_ssize_t size;
switch (PyCFunction_GET_FLAGS(func) & ~(METH_CLASS | METH_STATIC | METH_COEXIST)) {
case METH_VARARGS:
if (kw == NULL || PyDict_Size(kw) == 0)
return (*meth)(self, arg);
break;
case METH_VARARGS | METH_KEYWORDS:
case METH_OLDARGS | METH_KEYWORDS:
return (*(PyCFunctionWithKeywords)meth)(self, arg, kw);
case METH_NOARGS:
if (kw == NULL || PyDict_Size(kw) == 0) {
size = PyTuple_GET_SIZE(arg);
if (size == 0)
return (*meth)(self, NULL);
PyErr_Format(PyExc_TypeError,
"%.200s() takes no arguments (%zd given)",
f->m_ml->ml_name, size);
return NULL;
}
break;
case METH_O:
if (kw == NULL || PyDict_Size(kw) == 0) {
size = PyTuple_GET_SIZE(arg);
if (size == 1)
return (*meth)(self, PyTuple_GET_ITEM(arg, 0));
PyErr_Format(PyExc_TypeError,
"%.200s() takes exactly one argument (%zd given)",
f->m_ml->ml_name, size);
return NULL;
}
break;
case METH_OLDARGS:
/* the really old style */
if (kw == NULL || PyDict_Size(kw) == 0) {
size = PyTuple_GET_SIZE(arg);
if (size == 1)
arg = PyTuple_GET_ITEM(arg, 0);
else if (size == 0)
arg = NULL;
return (*meth)(self, arg);
}
break;
default:
PyErr_BadInternalCall();
return NULL;
}
PyErr_Format(PyExc_TypeError, "%.200s() takes no keyword arguments",
f->m_ml->ml_name);
return NULL;
}
1990-10-14 09:07:46 -03:00
/* Methods (the standard built-in methods, that is) */
static void
2000-07-09 03:03:25 -03:00
meth_dealloc(PyCFunctionObject *m)
1990-10-14 09:07:46 -03:00
{
2002-03-18 16:44:53 -04:00
_PyObject_GC_UNTRACK(m);
1997-05-02 00:12:38 -03:00
Py_XDECREF(m->m_self);
Py_XDECREF(m->m_module);
m->m_self = (PyObject *)free_list;
free_list = m;
1990-10-14 09:07:46 -03:00
}
2001-08-02 01:15:00 -03:00
static PyObject *
meth_get__doc__(PyCFunctionObject *m, void *closure)
{
const char *doc = m->m_ml->ml_doc;
2001-08-02 01:15:00 -03:00
if (doc != NULL)
return PyUnicode_FromString(doc);
2001-08-02 01:15:00 -03:00
Py_INCREF(Py_None);
return Py_None;
}
static PyObject *
meth_get__name__(PyCFunctionObject *m, void *closure)
{
return PyUnicode_FromString(m->m_ml->ml_name);
2001-08-02 01:15:00 -03:00
}
2001-07-12 10:27:35 -03:00
static int
meth_traverse(PyCFunctionObject *m, visitproc visit, void *arg)
{
Py_VISIT(m->m_self);
Py_VISIT(m->m_module);
return 0;
2001-07-12 10:27:35 -03:00
}
1997-05-02 00:12:38 -03:00
static PyObject *
2001-08-02 01:15:00 -03:00
meth_get__self__(PyCFunctionObject *m, void *closure)
{
2001-08-02 01:15:00 -03:00
PyObject *self;
Merged revisions 55270-55324 via svnmerge from svn+ssh://pythondev@svn.python.org/python/branches/p3yk ........ r55271 | fred.drake | 2007-05-11 10:14:47 -0700 (Fri, 11 May 2007) | 3 lines remove jpeg, panel libraries for SGI; there is more IRIX stuff left over, I guess that should be removed too, but will leave for someone who is sure ........ r55280 | fred.drake | 2007-05-11 19:11:37 -0700 (Fri, 11 May 2007) | 1 line remove mention of file that has been removed ........ r55301 | brett.cannon | 2007-05-13 17:38:05 -0700 (Sun, 13 May 2007) | 4 lines Remove rexec and Bastion from the stdlib. This also eliminates the need for f_restricted on frames. This in turn negates the need for PyEval_GetRestricted() and PyFrame_IsRestricted(). ........ r55303 | brett.cannon | 2007-05-13 19:22:22 -0700 (Sun, 13 May 2007) | 2 lines Remove the md5 and sha modules. ........ r55305 | george.yoshida | 2007-05-13 19:45:55 -0700 (Sun, 13 May 2007) | 2 lines fix markup ........ r55306 | neal.norwitz | 2007-05-13 19:47:57 -0700 (Sun, 13 May 2007) | 1 line Get the doc building again after some removals. ........ r55307 | neal.norwitz | 2007-05-13 19:50:45 -0700 (Sun, 13 May 2007) | 1 line Get test_pyclbr passing again after getstatus was removed from commands. This "test case" was weird since it was just importing a seemingly random module. Remove the import ........ r55322 | brett.cannon | 2007-05-14 14:09:20 -0700 (Mon, 14 May 2007) | 3 lines Remove the compiler package. Will eventually need a mechanism to byte compile an AST. ........
2007-05-14 19:03:55 -03:00
2001-08-02 01:15:00 -03:00
self = m->m_self;
if (self == NULL)
self = Py_None;
Py_INCREF(self);
return self;
}
static PyGetSetDef meth_getsets [] = {
2001-08-02 01:15:00 -03:00
{"__doc__", (getter)meth_get__doc__, NULL, NULL},
{"__name__", (getter)meth_get__name__, NULL, NULL},
{"__self__", (getter)meth_get__self__, NULL, NULL},
{0}
};
#define OFF(x) offsetof(PyCFunctionObject, x)
static PyMemberDef meth_members[] = {
{"__module__", T_OBJECT, OFF(m_module), WRITE_RESTRICTED},
{NULL}
};
1997-05-02 00:12:38 -03:00
static PyObject *
2000-07-09 03:03:25 -03:00
meth_repr(PyCFunctionObject *m)
1990-10-14 09:07:46 -03:00
{
if (m->m_self == NULL)
return PyUnicode_FromFormat("<built-in function %s>",
m->m_ml->ml_name);
return PyUnicode_FromFormat("<built-in method %s of %s object at %p>",
m->m_ml->ml_name,
m->m_self->ob_type->tp_name,
m->m_self);
1990-10-14 09:07:46 -03: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-23 21:41:19 -03:00
static PyObject *
meth_richcompare(PyObject *self, PyObject *other, int op)
{
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-23 21:41:19 -03:00
PyCFunctionObject *a, *b;
PyObject *res;
int eq;
if ((op != Py_EQ && op != Py_NE) ||
!PyCFunction_Check(self) ||
!PyCFunction_Check(other))
{
Py_INCREF(Py_NotImplemented);
return Py_NotImplemented;
}
a = (PyCFunctionObject *)self;
b = (PyCFunctionObject *)other;
eq = a->m_self == b->m_self;
if (eq)
eq = a->m_ml->ml_meth == b->m_ml->ml_meth;
if (op == Py_EQ)
res = eq ? Py_True : Py_False;
else
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-23 21:41:19 -03:00
res = eq ? Py_False : Py_True;
Py_INCREF(res);
return res;
}
static long
2000-07-09 03:03:25 -03:00
meth_hash(PyCFunctionObject *a)
{
long x,y;
if (a->m_self == NULL)
x = 0;
else {
1997-05-02 00:12:38 -03:00
x = PyObject_Hash(a->m_self);
if (x == -1)
return -1;
}
y = _Py_HashPointer((void*)(a->m_ml->ml_meth));
if (y == -1)
return -1;
x ^= y;
if (x == -1)
x = -2;
return x;
}
2001-08-02 01:15:00 -03:00
1997-05-02 00:12:38 -03:00
PyTypeObject PyCFunction_Type = {
PyVarObject_HEAD_INIT(&PyType_Type, 0)
"builtin_function_or_method",
2002-03-18 16:44:53 -04:00
sizeof(PyCFunctionObject),
1990-10-14 09:07:46 -03:00
0,
2001-07-12 10:27:35 -03:00
(destructor)meth_dealloc, /* tp_dealloc */
0, /* tp_print */
2001-08-02 01:15:00 -03:00
0, /* tp_getattr */
2001-07-12 10:27:35 -03:00
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-23 21:41:19 -03:00
0, /* tp_compare */
2001-07-12 10:27:35 -03:00
(reprfunc)meth_repr, /* tp_repr */
0, /* tp_as_number */
0, /* tp_as_sequence */
0, /* tp_as_mapping */
(hashfunc)meth_hash, /* tp_hash */
PyCFunction_Call, /* tp_call */
2001-07-12 10:27:35 -03:00
0, /* tp_str */
2001-08-02 01:15:00 -03:00
PyObject_GenericGetAttr, /* tp_getattro */
2001-07-12 10:27:35 -03:00
0, /* tp_setattro */
0, /* tp_as_buffer */
2002-03-18 16:44:53 -04:00
Py_TPFLAGS_DEFAULT | Py_TPFLAGS_HAVE_GC,/* tp_flags */
2001-07-12 10:27:35 -03:00
0, /* tp_doc */
(traverseproc)meth_traverse, /* tp_traverse */
2001-08-02 01:15:00 -03:00
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-23 21:41:19 -03:00
meth_richcompare, /* tp_richcompare */
2001-08-02 01:15:00 -03:00
0, /* tp_weaklistoffset */
0, /* tp_iter */
0, /* tp_iternext */
0, /* tp_methods */
meth_members, /* tp_members */
2001-08-02 01:15:00 -03:00
meth_getsets, /* tp_getset */
0, /* tp_base */
0, /* tp_dict */
1990-10-14 09:07:46 -03:00
};
1990-12-20 11:06:42 -04:00
/* Find a method in a method chain */
1990-12-20 11:06:42 -04:00
1997-05-02 00:12:38 -03:00
PyObject *
Py_FindMethodInChain(PyMethodChain *chain, PyObject *self, const char *name)
1990-12-20 11:06:42 -04:00
{
if (name[0] == '_' && name[1] == '_') {
if (strcmp(name, "__doc__") == 0) {
const char *doc = self->ob_type->tp_doc;
if (doc != NULL)
return PyUnicode_FromString(doc);
}
}
while (chain != NULL) {
1997-05-02 00:12:38 -03:00
PyMethodDef *ml = chain->methods;
for (; ml->ml_name != NULL; ml++) {
if (name[0] == ml->ml_name[0] &&
strcmp(name+1, ml->ml_name+1) == 0)
/* XXX */
1997-05-02 00:12:38 -03:00
return PyCFunction_New(ml, self);
}
chain = chain->link;
1990-12-20 11:06:42 -04:00
}
1997-05-02 00:12:38 -03:00
PyErr_SetString(PyExc_AttributeError, name);
1990-12-20 11:06:42 -04:00
return NULL;
}
/* Find a method in a single method list */
1997-05-02 00:12:38 -03:00
PyObject *
Py_FindMethod(PyMethodDef *methods, PyObject *self, const char *name)
{
1997-05-02 00:12:38 -03:00
PyMethodChain chain;
chain.methods = methods;
chain.link = NULL;
1997-05-02 00:12:38 -03:00
return Py_FindMethodInChain(&chain, self, name);
}
/* Clear out the free list */
void
2000-07-09 03:03:25 -03:00
PyCFunction_Fini(void)
{
while (free_list) {
PyCFunctionObject *v = free_list;
free_list = (PyCFunctionObject *)(v->m_self);
2002-03-18 16:44:53 -04:00
PyObject_GC_Del(v);
}
}
/* PyCFunction_New() is now just a macro that calls PyCFunction_NewEx(),
but it's part of the API so we need to keep a function around that
existing C extensions can call.
*/
#undef PyCFunction_New
PyAPI_FUNC(PyObject *) PyCFunction_New(PyMethodDef *, PyObject *);
PyObject *
PyCFunction_New(PyMethodDef *ml, PyObject *self)
{
return PyCFunction_NewEx(ml, self, NULL);
}