Robert Bradshaw wrote: > On Oct 16, 2009, at 12:29 AM, Dag Sverre Seljebotn wrote: > >> Robert Bradshaw wrote: >>> On Oct 15, 2009, at 4:59 PM, Lisandro Dalcin wrote: >>> >>>> On Thu, Oct 15, 2009 at 10:40 AM, Stefan Behnel >>>> <[email protected]> >>>> wrote: >>>>> >>>>> Neal Becker wrote: >>>>>> I think this works: >>>>>> >>>>>> 1) In numpy.pxd, use: >>>>>> from python_ref cimport PyObject >>>>>> >>>>>> 2) In sum.pyx: >>>>>> >>>>>> from python_ref cimport Py_XINCREF, Py_XDECREF, PyObject >>>>> Yes, that should be ok. >>>>> >>>>> I looked around a bit more in Cython/Includes/, and it seems like >>>>> it >>>>> really >>>>> needs some broader cleanup. There are a couple of redefinitions of >>>>> PyObject >>>>> and various function definitions that use PyObject* and should use >>>>> object >>>>> instead. >>>>> >>>> Could we use this for PyObject ?: >>>> >>>> ctypedef struct PyObject >>> The question is whether to allow casting objects to any struct >>> pointer, or making PyObject special. Another option would be to >>> give a >>> syntax to mark structs as raw versions of objects, which could handle >>> PyTypeObject, etc. >>> >>> I'm with Greg, however, that most of the time we should be looking at >>> the usecases and deciding if we can avoid having to treat objects as >>> pointers. (E.g. being able to declare a variable as an object that >>> might be NULL.) That being said, I'm not sure it's possible to come >>> up >>> with nice solutions to everything, and if the user wants to do >>> something messy maybe we shouldn't be adding it to the language. >> Even so, there's a lot of code which already uses various forms of >> custom-declared PyObject*. My primary concern here is that I think we >> should go further with disallowing >> >> <SomeType*>myobject >> >> If we include PyObject as a builtin type, it becomes possible to allow >> <PyObject*>myobject but disallow the above. >> >> Even if we do add syntax features for dealing with these situations >> (declaring borrowed and stolen references and objects which can be >> NULL...personally I'm starting to think there is too much >> special-purpose syntax already...) it's quite a matter to break >> backwards compatability and disallow existing code from getting a >> PyObject*! Requiring that people remove their own definitions of >> PyObject and use the builtin instead is much less of a matter. >> >> So I'd say there's a case for >> >> a) Add a builtin PyObject* >> b) Once that is done, start emitting warning for anything but >> <void*>myobject and <PyObject*>myobject (the builtin one only); then >> emit an error in the next release. > > I'm not entirely convinced. For one thing, I'd rather people have to > cimport PyObject rather than have it by default in the namespace (as > most people should not be using it at all, so it would make thing more > confusing/encourage bad code). Is <SomeType*>myobject really so bad? >
There's e.g. an issue with structs as dtypes to ndarrays: # 1) Forget to do this: cdef np.ndarray[SomeStruct] typedarr # 2) Then: typedarr = arr call_f_func(<SomeStruct*>arr.data) # hope for segfault This silently converts a Python buffer object to a SomeStruct*, rather than getting the underlying pointer that we wanted. As casting an object to a SomeStruct never makes sense... however I guess for *some* structs, it makes sense. The problem might be though that I should have renamed the "data" field for ndarray Cython-side instead of keeping it in numpy.pxd -- called it raw_data or buf instead. -- Dag Sverre _______________________________________________ Cython-dev mailing list [email protected] http://codespeak.net/mailman/listinfo/cython-dev
