[Python-Dev] Possible bug in complexobject.c (still in Python 2.5)
I'm curious about the difference between float_subtype_new in floatobject.c complex_subtype_from_c_complex in complexobject.c The former uses type-tp_alloc(type, 0) to create memory for the object while the latter uses PyType_GenericAlloc(type, 0) to create memory for the sub-type (thereby by-passing the sub-type's own memory allocator). It seems like this is a bug. Shouldn't type-tp_alloc(type, 0) also be used in the case of allocating complex subtypes? This is causing problems in NumPy because we have a complex type that is a sub-type of the Python complex scalar. It sometimes uses the complex_new code to generate instances (so that the __new__ interface is the same), but because complex_subtype_from_c_complex is using PyType_GenericAlloc this is causing errors. I can work around this by not calling the __new__ method for the base type but this is not consistent. Thanks for any feedback, -Travis ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Possible bug in complexobject.c (still in Python 2.5)
I'm curious about the difference between float_subtype_new in floatobject.c complex_subtype_from_c_complex in complexobject.c The former uses type-tp_alloc(type, 0) to create memory for the object while the latter uses PyType_GenericAlloc(type, 0) to create memory for the sub-type (thereby by-passing the sub-type's own memory allocator). It seems like this is a bug. Shouldn't type-tp_alloc(type, 0) also be used in the case of allocating complex subtypes? This is causing problems in NumPy because we have a complex type that is a sub-type of the Python complex scalar. It sometimes uses the complex_new code to generate instances (so that the __new__ interface is the same), but because complex_subtype_from_c_complex is using PyType_GenericAlloc this is causing errors. I can work around this by not calling the __new__ method for the base type but this is not consistent. Thanks for any feedback, P.S. Sorry about the cross-posting to another thread. I must have hit reply instead of compose. Please forgive the noise. -Travis ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Possible bug in complexobject.c (still in Python 2.5)
I wouldn't be surprised if this is a genuine bug; the complex type doesn't get a lot of love from core developers. Could you come up with a proposed fix, and a unit test showing that it works (and that the old version doesn't)? (Maybe a good unit test would require writing a custome C extension; in that case just show some sample code.) --Guido On 5/31/06, Travis E. Oliphant [EMAIL PROTECTED] wrote: I'm curious about the difference between float_subtype_new in floatobject.c complex_subtype_from_c_complex in complexobject.c The former uses type-tp_alloc(type, 0) to create memory for the object while the latter uses PyType_GenericAlloc(type, 0) to create memory for the sub-type (thereby by-passing the sub-type's own memory allocator). It seems like this is a bug. Shouldn't type-tp_alloc(type, 0) also be used in the case of allocating complex subtypes? This is causing problems in NumPy because we have a complex type that is a sub-type of the Python complex scalar. It sometimes uses the complex_new code to generate instances (so that the __new__ interface is the same), but because complex_subtype_from_c_complex is using PyType_GenericAlloc this is causing errors. I can work around this by not calling the __new__ method for the base type but this is not consistent. Thanks for any feedback, -Travis ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/guido%40python.org -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Possible bug in complexobject.c (still in Python 2.5)
Guido (Maybe a good unit test would require writing a custome C Guido extension; in that case just show some sample code.) Isn't that what Module/_testcapimodule.c is for? Skip ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Possible bug in complexobject.c (still in Python 2.5)
Guido van Rossum wrote:
I wouldn't be surprised if this is a genuine bug; the complex type
doesn't get a lot of love from core developers.
Could you come up with a proposed fix, and a unit test showing that it
works (and that the old version doesn't)? (Maybe a good unit test
would require writing a custome C extension; in that case just show
some sample code.)
Attached is a sample module that exposes the problem. The problem goes
away by replacing
op = PyType_GenericAlloc(type, 0);
with
op = type-tp_alloc(type, 0);
in the function
complex_subtype_from_c_complex
in the file complexobject.c (about line #191).
The problem with a unit test is that it might not fail. On my Linux
system, it doesn't complain about the problem unless I first use strict
pointer checking with
export MALLOC_CHECK_=2
Then the code
import bugtest
a = bugtest.newcomplex(3.0)
del a
Aborts
Valgrind also shows the error when running the simple code. It seems
pretty clear to me that the subtype code should be calling the sub-types
tp_alloc code instead of the generic one.
Best regards,
-Travis
#include Python.h
typedef struct {
PyObject_HEAD
double real;
double imag;
} PyNewComplexObject;
static PyTypeObject PyComplex_SubType = {
PyObject_HEAD_INIT(NULL)
0, /*ob_size*/
newcomplex, /*tp_name*/
sizeof(PyNewComplexObject),/*tp_basicsize*/
};
static PyObject *
_complex_alloc(PyTypeObject *type, int nitems)
{
PyObject *obj;
obj = (PyObject *)malloc(_PyObject_SIZE(type));
memset(obj, 0, _PyObject_SIZE(type));
PyObject_INIT(obj, type);
return obj;
}
PyMODINIT_FUNC initbugtest(void) {
PyObject *m, *d;
m = Py_InitModule(bugtest, NULL);
d = PyModule_GetDict(m);
PyComplex_SubType.tp_free = free;
PyComplex_SubType.tp_alloc = _complex_alloc;
PyComplex_SubType.tp_base = PyComplex_Type;
PyComplex_SubType.tp_flags = Py_TPFLAGS_DEFAULT | Py_TPFLAGS_CHECKTYPES;
PyType_Ready(PyComplex_SubType);
Py_INCREF(PyComplex_SubType);
PyDict_SetItemString(d, newcomplex,
(PyObject *)PyComplex_SubType);
return;
}
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Possible bug in complexobject.c (still in Python 2.5)
Travis E. Oliphant wrote: I'm curious about the difference between float_subtype_new in floatobject.c complex_subtype_from_c_complex in complexobject.c The former uses type-tp_alloc(type, 0) to create memory for the object while the latter uses PyType_GenericAlloc(type, 0) to create memory for the sub-type (thereby by-passing the sub-type's own memory allocator). It seems like this is a bug. Shouldn't type-tp_alloc(type, 0) also be used in the case of allocating complex subtypes? I submitted an entry and a patch for this on SourceForge Tracker (#1498638) http://sourceforge.net/tracker/index.php?func=detailaid=1498638group_id=5470atid=105470 -Travis ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
