Message168536
| Author |
Robin.Schreiber |
| Recipients |
Robin.Schreiber, ezio.melotti, loewis, mark.dickinson, mrabarnett, pitrou, rhettinger, skrah |
| Date |
2012年08月18日.22:36:33 |
| SpamBayes Score |
-1.0 |
| Marked as misclassified |
Yes |
| Message-id |
<1345329400.69.0.320813862108.issue15722@psf.upfronthosting.co.za> |
| In-reply-to |
| Content |
I have removed some redundant modulestate lookups and the testsuite now executes the decimal tests as fast as before the patch is applied. (at least for me).
May I ask how you tested the decimal performance?
Regarding the failing test:
It appears that the hackcheck() method in typeobject.c is responsible for this failure:
static int
hackcheck(PyObject *self, setattrofunc func, char *what)
{
PyTypeObject *type = Py_TYPE(self);
while (type && type->tp_flags & Py_TPFLAGS_HEAPTYPE)
type = type->tp_base;
/* If type is NULL now, this is a really weird type.
In the spirit of backwards compatibility (?), just shut up. */
if (type && type->tp_setattro != func) {
PyErr_Format(PyExc_TypeError,
"can't apply this %s to %s object",
what,
type->tp_name);
return 0;
}
return 1;
}
As the context-type is now a heaptype the while-loop will continue to jump to the basetype of the conext-type, which is the object-type. There it ultimately fails when it compares func (context_setattr) to the tp_setattr of object.
Anyway, I do not understand the purpose of the hackcheck method, so I can not propose any kind of solution for this problem. |
|