Exposing buffer interface for non-extension types?

[Ken Watford]

On Tue, Jul 20, 2010 at 9:26 PM, Robert Kern <robert.kern at 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_ml at 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.