On Tue, Jul 20, 2010 at 9:26 PM, Robert Kern <robert.k...@gmail.com> wrote: > On 7/20/10 8:38 PM, Ken Watford wrote: >> >> On Tue, Jul 20, 2010 at 6:58 PM, Stefan Behnel<stefan...@behnel.de> >> wrote: >>> >>> Ken Watford, 21.07.2010 00:09: >>>> >>>> Is there any way to expose the PEP 3118 buffer interface for objects >>>> that aren't extension types? >>> >>> Given that it's a pure C-level interface, I don't think there would be >>> much >>> use for that. >> >> Perhaps, but *why* is it only a pure C-level interface? It's based >> on/inspired by the array interface, which was not a pure C-level >> interface. Did they simply neglect to provide the functionality due to >> lack of obvious use cases, or did they consciously decide to drop thaThat >> functionality? > > Lack of obvious use cases. The primary use case is for C extensions to > communicate with each other. SWIG is the odd man out in that it does not > create true extension types. While the functionality of the PEP derives from > numpy's interface, it's inclusion in Python was largely seen as the > extension of the older buffer interface which is also a pure C interface. > > The Python-level __array_interface__ numpy API is not and will not be > deprecated despite some outdated language in the documentation. Please > continue to use it.
Thanks, that's good to know. (Someone should probably do something about the big red box that says the opposite in the current docs). I assume the same is true about __array_struct__? Since it *is* an extension despite the non-extension types, filling in a structure is a little more convenient than building the dictionary. -- http://mail.python.org/mailman/listinfo/python-list
