Stefan Behnel wrote: > That sounds a bit like you are objecting to my proposal. What would you see as > a better solution then?
Make the relevant C struct a built-in Cython type (a plain C struct, not an extension type) and expose the buffer slots exactly the way they are. The purpose of the buffer interface is to provide a direct C-level window into the internals of the object, with as little in the way as possible. > I mean, we will have to support the buffer interface in one way or another, > and we will have to do it in a way that works on Py3 and compiles on Py2. It'll be difficult to have the same Cython source work for both. It might be doable by giving the new buffer slots different names in Cython, and generating a wrapper that emulates the old buffer interface using the new one when compiling in py2 mode. (A purely C-level wrapper, not involving any extra Python objects.) That might enable code that provides an old-style buffer interface to work with py3, although you may run into problems with the need for locking. I don't think going the other way will be feasible, since the new buffer interface has capabilities that you can't emulate using the old one. > Cython is all about writing C code without writing C code. I would really > prefer a solution that does not require going all the way down to C-ish code, > just to implement a Python object protocol. But the buffer interface is *not* a Python protocol, it's a C protocol. You can't avoid C-level issues when you're dealing with it. -- Greg _______________________________________________ Cython-dev mailing list [email protected] http://codespeak.net/mailman/listinfo/cython-dev
