On 1/5/07, Travis Oliphant <oliphant@ee.byu.edu> wrote:
Charles R Harris wrote:

>
>
> On 1/5/07, *Stefan van der Walt* <stefan@sun.ac.za
> <mailto:stefan@sun.ac.za>> wrote:
>
>     On Fri, Jan 05, 2007 at 09:38:49AM -0500, Neal Becker wrote:
>     >     Several extensions to Python utilize the buffer protocol to
>     share
>     >     the location of a data-buffer that is really an N-dimensional
>     >     array.  However, there is no standard way to exchange the
>     >     additional N-dimensional array information so that the
>     data-buffer
>     >     is interpreted correctly.
>     >
>     > I am questioning if this is the best concept.  It says that the
>     data-buffer
>     > will carry the information about it's interpretation as an
>     N-dimensional
>     > array.
>     >
>     > I'm thinking that a buffer is just an interface to memory, and
>     that the
>     > interpretation as an array of n-dimensions, for example, is best
>     left to
>     > the application.  I might want to at one time view the data as
>     > n-dimensional, but at another time as 1-dimensional, for example.
>
>     You can always choose to ignore that information if you don't need it.
>     On the other hand, if you *do* need it, how would you otherwise
>     interpret an N-dimensional array, given only a buffer?
>
>
> I think Neal is suggesting some object that basically does nothing but
> hold a pointer(s) to memory. This memory can be used in various ways,
> one of which is to use it construct another type of object that
> provides a view with indices and such, i.e., an array. That way the
> memory isn't tied to arrays and could concievable be used in other
> ways. The idea is analagous to the data/model/view paradigm. It is a
> bit cleaner than just ignoring the array parts.

Such an object would be useful.  I would submit that it is what the
buffer object "should be"

Yeah. The problem is that we have a buffer API, not a buffer object.

Chuck