Dag Sverre Seljebotn wrote: > Stefan Behnel wrote: > >> Dag Sverre Seljebotn wrote: >> >>> As for Python 2.6, it appears that we have the option to generate >>> objects using the new buffer slots, but we can also generate objects >>> without. Thoughts? >>> >>> Mine: At least as long as NumPy doesn't implement this for 2.6, I'd like >>> to stay with emulation. If I get the time then perhaps a "dual-mode" >>> where the slots are checked first, and if the object doesn't have the >>> slots (i.e. the flags of the type is set to not supporting the new >>> buffers) then emulation is used. >>> >> If I understand correctly, you only refer to /getting/ the buffer of a >> however implemented object, not about implementing the __getbuffer__() >> method, right? So Cython implemented buffer objects would have their >> __getbuffer__() in any case? >> > > Not sure I understand this. > > The point anyway is that Cython currently does not fill the getbuffer > slot on Py2.6. However, if we added Py_TPFLAGS_HAVE_NEWBUFFER to the > type flags it seems we could do this, right? (I don't know much about > these things so I'll have to listen to you here.) > > So the real question is whether we should change things so that > bf_getbuffer is filled in under Py2.6; I suppose this calls for changing > tp_flags on the classes which has __getbuffer__ or __releasebuffer__ > implemented. > > The whole reason I started using Cython and the PyObject_GetBuffer() stuff is to move my code (e.g. http://code.astraw.com/projects/motmot/browser/trunk/FastImage/src/FastImage.pyx ) away from the __array_interface__ and __array_struct__ conventions and move to the now standard Python mechanism. I'd much prefer to do this with 2.6 than 3.0. Two serious issues with not doing it:
1) The lack of proper inheritance for the Cython workaround. 2) Without serious hoop-jumping, it would require use of Cython on the other side of the buffer interface rather than using the normal Python mechanism to use the Cython emulation. Also, don't forget that since 2.6 will support PyObject_GetBuffer(), Cython should consume those buffers on 2.6, regardless of whether Cython extension types fill the slot. So, I'm +1 that Cython should fill bf_getbuffer slots in 2.6. It seems to me this is only a matter of adjusting the #ifdef statements emitted by Cython, so I don't see why this is much of an issue. The benefits to me greatly outweigh the drawbacks. The only which I know of is: > (And then I will continue to also support emulation for object which > don't have Py_TPFLAGS_HAVE_NEWBUFFER, in case libraries are simply > recompiled for 2.6). > > I think forcing those people to re-run a newer Cython on they .pyx files is an acceptable solution. I can't imagine there are many people in this boat yet, and if so, their code is fresh enough that a re-compilation is probably not much effort. Remember that this is only a problem for Python 2.6, which isn't even released yet. I do understand that the already emitted C code shouldn't have to be re-compiled. In any case, if implementing support for the Cython emulation is a pain when the real PyObject_GetBuffer() exists, you could simply put it off for now with code that raises an error and tells the user to either to re-compile their .pyx files or to implement such support. >> I don't see why we shouldn't support getting the buffer of /any/ object >> that support the buffer protocol, be it in 2.6 or 3.0, instead of just >> special casing NumPy. I do agree, however, that this is not a short-term >> requirement. I think a dual-mode of NumPy special casing and generic >> buffer support would be the best solution. The code for both is there >> anyway, right? >> > > NumPy isn't special cased as such, it is an emulation mechanism by > putting __getbuffer__ in numpy.pxd (and any other pxd). Comes close though. > > But the point is that no Cython classes support the buffer protocol > under 2.6 in current Cython. If numpy gains first class support for PyObject_GetBuffer() in the 2.6 time frame (quite possible, I think, considering that Travis Oliphant wrote PEP 3118), then Cython should not use it's __getbuffer__ implementation for numpy but defer to the ndarray type object's bg_getbuffer slot. (Perhaps is not as likely, now, given that you've given an easy path with Cython. Nonetheless, we shouldn't force the consumers to write Cython code to use this feature with Python 2.6 -- my issue #2 above.) -Andrew _______________________________________________ Cython-dev mailing list [email protected] http://codespeak.net/mailman/listinfo/cython-dev
