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. Dag Sverre _______________________________________________ Cython-dev mailing list [email protected] http://codespeak.net/mailman/listinfo/cython-dev
