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