On 7/20/10 9:39 PM, Ken Watford wrote:
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 just did. I'm sorry; we had a discussion about that some time ago, and I
thought we had removed it then.
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.
Yes, __array_struct__ is also not deprecated.
--
Robert Kern
"I have come to believe that the whole world is an enigma, a harmless enigma
that is made terrible by our own mad attempt to interpret it as though it had
an underlying truth."
-- Umberto Eco
--
http://mail.python.org/mailman/listinfo/python-list
