Stefan Behnel wrote: > Hi Dag, > > Dag Sverre Seljebotn wrote: >> I'm wondering if I could move Py_buffer out of the default scope, in >> order to reduce the namespace incompatability. (Py_buffer is present in >> the global scope for the purposes of the second argument to >> __getbuffer__ and __releasebuffer__ ). The alternatives I see are either >> "cython.Py_buffer" or "python_buffer.Py_buffer" (or both), where you >> need to cimport cython/python_buffer first. > > I see Py_buffer in a similar light as Py_ssize_t. Would you also argue for > that being moved into a separate namespace?
I would, but that is water under the bridge now -- it would call for a round of deprecation warnings etc., so might as well leave it until Python compatability is otherwise much higher (though if Py_buffer is moved, one should definitly create cython.Py_ssize_t as well now as an alias). The point is that Py_buffer is probably not used in any code yet, or if it is, it is only for Py3 beta purposes, so a deprecation warning round is not needed IMO. > Since Py_buffer is a requirement for implementing a standard Python C-API > method, I think it makes sense to keep it in the global namespace as a > standard data type of Cython. Yes, and I mentioned this counter-argument too. For me it weighs less than a higher degree of Python compatability. I don't mind letting __builtin__ be strictly Python API, and require imports for using the C-API in any way (or anything else that we add above pure Python). Anyway, the only reason I'm bringing it up now is the timing, and seeing that you didn't like it I'm ready to drop it. (While on namespace issues, the Tao says "flat is better than nested" which is in favor of cython.shape rather than cython.buffer.shape?) -- Dag Sverre _______________________________________________ Cython-dev mailing list [email protected] http://codespeak.net/mailman/listinfo/cython-dev
